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 [EMAIL PROTECTED]
