Philip Taylor <[EMAIL PROTECTED]> wrote: > 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:
Wow. > * 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? No, keeping the ops in their categories is fine. > * 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?) A method, like e.g. C<eof>, see classes/parrotio.pmc $P0 = getstding $I0 = $P0."__isatty"() METHOD INTVAL __isatty() ... (we'll create the mangled version with two underscores automagically soon) > * Is it possible to merge PBC files together, like load_bytecode but at > compile-time? Not really. But you might have a look at src/pbc_info.c, which demonstrates some of the packfile manipulations. Such a utility would be really great. > * 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?) It's a bit early still, but a general rule of thumb is: - if you have native I or N types, make it an opcode - everything else is at least a function call already and will be optimized like hell and will be fast enough ;) > 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. That (but not only) seems to warrant new {Fixed,Resizable}ByteArray PMCs. See e.g. the *BooleanArray PMCs. > 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? :-) WRT "memory" access probably yes. When it comes to raw calculation speed with INTVALs, Parrot can reach the speed of optimized C. > Thanks, Welcome, leo