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
