According to Philip Taylor:
> * 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).
Don't you also need unsigned assignment to N registers?
double d = 0xFFFFFFFFUL;
> 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?
May as well leave them there.
> * Should there be an 'isatty' op/method?
I think so. I wouldn't tie it to the fileno() concept, because
fileno() is less portable than isatty(filehandle), which is a
reasonable sort of question beyond the bounds of Unix, in the Great
Wilderness.
> * Is it possible to merge PBC files together, like load_bytecode but at
> compile-time?
I'll punt on this one for now... Leo?
> 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
Yes ... on some arch's. Not x86, though, so I'm safe. :-)
> but IMC code like "val = mem.read_i1(ptr)" feels unpleasantly
> inefficient, particularly in string-processing loops.
What about a native-code _function_ rather than an object method?
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
Open Source is not an excuse to write fun code
then leave the actual work to others.
