Content deleted Content added
→First sentence is wrong: Other scientific word sizes |
→incorrect use of term bytecode: 1 to 56 byte instructions! |
||
Line 63:
The focus should probably be on 'byte-oriented', in the sense of simplifying instruction decoding. The op-code is only one of several fields -- it is not a great benefit if the op-code is easy to extract, while other fields are complex. I've always thought the instruction encoding used for the EM-1 'machine' was a good example: opcode is one byte, escape sequence is one byte, and address fields is one or two bytes. There are a few exceptions where the instructions and arguments were encoded into one byte, but this was to speed execution of very common instructions. (See Informatica Report IR-81 (from 1983) by Andrew S Tanenbaum et al.: Description of a machine architecture for use with block structured languages.) Although the term 'bytecode' is not used by the authors, it has been used in descriptions of the Amsterdam Compiler Kit, of which EM-1 was a central concept.[[User:Athulin|Athulin]] ([[User talk:Athulin|talk]]) 09:46, 10 January 2011 (UTC)
:
:Yes. [[VAX]] was well designed for byte-by-byte interpreters, specifically a microcoded processor. But that was its main failure. It does not lead to parallel or OoO execution. Each operand has a one byte operand descriptor, followed by the appropriate number of operand bytes. To find the next instruction, you have to process all the operand descriptor bytes, one by one. Even though DEC hoped for a long life for VAX, after not so many years, they went to the RISC architecture [[Alpha AXP|Alpha]]. VAX instructions can be 1 to 56 bytes long, I suspect a wider range than JVM. [[User:Gah4|Gah4]] ([[User talk:Gah4|talk]]) 20:29, 14 August 2025 (UTC)
==Layman's terms==
| |||