Various questions

I've been working on a C-to-Parrot compiler (actually an IMC backend
for the LCC compiler), tentatively named Carrot, over the past week. It
can currently do some reasonably useful things, like running the Cola
compiler (with only a very small amount of cheating), but it has raised 
a few queries:

* I can usually handle unsigned numbers by pretending they're signed and 
using 'I' registers, but some things appear to be awkward without new 
ops - in particular, div and cmod, and le/lt/ge/gt comparisons. (As far 
as I can tell, those are the only ones C would need; everything else 
should work fine with the signed variants).

I've added divu/leu/etc ops to math.ops/cmp.ops (and just made them cast 
their operands into UINTVALs) - is that a reasonable thing to do? Would 
they be better in a new .ops file?


* Should there be an 'isatty' op/method? (or is there something else 
that "isatty(fileno(file))" (which Cola's lexer uses) should do, in 
order to return a reasonable answer?)


* Is it possible to merge PBC files together, like load_bytecode but at 
compile-time?

The compiler converts .c to .pbc (via .imc), then the linker just 
creates a program full of load_bytecode, so the actual linking gets done 
at run-time, which isn't very nice when you try moving/deleting one of 
the .pbcs. (And lcc always deletes the .pbcs, since it assumes they're 
temporary files.)


* How efficient are PMC method calls? (And are performance concerns 
documented anywhere, like "op calls are roughly n times faster than 
methods", so compiler-writers could avoid implementing things in stupid 
ways, or is it too early to be doing that?)

I've been using [gs]et_integer_keyed_int on a PMC to allow pointer 
access. Since it reads whole ints, it probably crashes unnecessarily 
when e.g. reading chars at unlucky addresses - but IMC code like "val = 
mem.read_i1(ptr)" feels unpleasantly inefficient, particularly in 
string-processing loops.

Hmm... Should I just accept that C-on-Parrot will always be relatively 
slow, since its concept of memory is slightly incompatible with 
Parrot's, and anybody who wants speed can use a native C compiler, so I 
can stop worrying about it? :-)


Thanks,
-- 
Philip Taylor
philip@zaynar.demon.co.uk

• Various questions by Philip Taylor
• Re: Various questions by Leopold Toetsch
• Re: Various questions by Chip Salzenberg