Front page | perl.perl6.internals |
Postings from February 2002
On Monday 11 February 2002 16:19, Andy Dougherty wrote: > On Mon, 11 Feb 2002, Bryan C. Warnock wrote: > > On Monday 11 February 2002 15:37, Gregor N. Purdy wrote: > > > IIRC sizeof(opcode_t) === 4, since it is required that opcode_t be 32 > > > bits. So, that 4 is supposed to be a 4, although turning it into a > > > symbolic constant is not a bad idea. Using sizeof(opcode_t) as that > > > constant isn't evil either, although I don't think its necessary. > > > > Nope. sizeof(opcode_t) >= 32 and sizeof(opcode_t) <= sizeof(INTVAL). > > The *contents* are limited to 32 bits, but the container is not. > > (64-bit efficiency hack.) > > It's much more than just an efficiency hack. A legal C implementation can > actually have no 32-bit type. It is perfectly legal to have sizeof(short) > == sizeof(int) == sizeof(long) == 8 (64-bit), and some Crays indeed work > exactly that way. I don't think we want to force such systems to use > bitfields or some such for opcodes. Exactly. Hence allowing 64 bit opcodes for more effeciency. ;-) > > Further, though the contents are *supposed* to be limited to 32 bits, I > didn't come across any place in the code where that limit was actually > imposed. The assembler should handle this on input. A sandbox should handle this on runthrough. I think we decided not to enforce it within the regular opcode loop. -- Bryan C. Warnock bwarnock@capita.comThread Previous