> Oh, they'll be able to have 64 (or 128, or 256) bit IVs. That's fine. It's
> just the in-stream integer constants that might be limited to 32 bits for > portability reasons. Probably have to do some sort of odd: > > set I0, 0x12345678 > lshift I0, 32 > add I0, I0, 0x9ABCDEF0 I like to repeat my previous argument. The opcode stream should be strict stream of 32-bit signed integer stream. The data type for the actual stream may be different from int32_t. Don't try to make opcode bigger and use it for additional feature. The opcode is bloated already (using 32-bit for 5-bit register index). For the portability, we need at least 3 data types for opcode: 1) in memory representation, most likely int32_t. Almost all 64-bit systems (except Cray maybe) have efficient 32-bit instructions. Using 32-bit opcode instead of 64-bit will significant improve memory footprint and cache locality. 2) portable in file representation, most likely big-endian 4-byte two's complement integer. This is the most commonly used format for internet world. 3) native in file representation, which is most likely be mirror of 1), so we can mmap the bytecode file. By the way, we should never use code to generate 64-bit value. We have constant area, where you can put anything in it, including bigint and bigfloat. Hong
