> 8-byte word: endianness (magic value 0x123456789abcdef0) > byte: word size > byte[7]: empty > word: major version > word: minor version > > Where all word values are as big as the word size says they are. > > The magic value can be something else, but it should byteswap such that if > you read it in you can tell whether it was a big-endian write or a > little-endian write. Since the magic value can tell the endian, there is really no need for the endianness field. Personally I don't like the word size concept. I prefer we use fixed 4-byte word. If we support multiple word size, each runtime have to deal with several bytecode data format, 2, 4, 6, 8-byte word. I believe the 4-byte word will be 99+% of all practical use. We should let minority convert it, instead of asking every runtime to handle every thing. Hong
- Re: RFC: Bytecode file format Jarkko Hietaniemi
- Re: RFC: Bytecode file format Buddha Buck
- Re: RFC: Bytecode file format Dan Sugalski
- Re: RFC: Bytecode file format Brian Wheeler
- Re: RFC: Bytecode file format Dan Sugalski
- Re: RFC: Bytecode file format Jarkko Hietaniemi
- Re: RFC: Bytecode file format Jarkko Hietaniemi
- Re: RFC: Bytecode file format Jarkko Hietaniemi
- Re: RFC: Bytecode file format Gregor N. Purdy
- RE: RFC: Bytecode file format Hong Zhang
- RE: RFC: Bytecode file format Dan Sugalski
- Re: RFC: Bytecode file format Benjamin Stuhl
- RE: RFC: Bytecode file format Brent Dax
- Re: RFC: Bytecode file format Brian Wheeler
- RE: RFC: Bytecode file format Hong Zhang
- Re: RFC: Bytecode file format Jarkko Hietaniemi
- Re: RFC: Bytecode file format Benjamin Stuhl
- RE: RFC: Bytecode file format Hong Zhang
- Re: RFC: Bytecode file format Jarkko Hietaniemi
- Re: RFC: Bytecode file format Jarkko Hietaniemi