3 ms·

IEEE Spectrum in the early 80's had an article on minimal instruction sets. The author made a salient point that 7 instructions did most of the heavy lifting, a

IEEE Spectrum in the early 80's had an article on minimal instruction sets. The author made a salient point that 7 instructions did most of the heavy lifting, another 7 did the most of the rest required. He did highlight that one mistake made with instruction sets was not separating the addressing modes from the instruction itself. There have also been various projects looking at the micro-instruction based machines and noting that extremely complex instruction sets could be designed so that the actual requirements of a programmer or project be placed in microcode. One example was an instruction to search a tree structure for a required value (as a single machine instruction). Not that I can do anything about it, my conclusion over nearly 4 decades is that we have failed to take advantage of the increasingly denser silicon to make higher level machines, in particular machines that recognise the difference an instruction and a data element. We can write very high level software languages but all have to be run on extremely low level hardware. Too much commodity and not enough variability.

adyavanapalli 9y ago
Can you please link that article?
- oldandtired 9y ago
  See my comment above.
djsumdog 9y ago
Are you talking about Very Long Instruction Words (VLIW)? IIRC, that's the concept of having the scheduling done in the compiler. Instead of the compiler spitting out op codes and operands, each part of the instruction space controls specific functional units. So if you stick something in the adder, the documentation might specify the next x instructions need to be nops so it can complete. The idea being if scheduling is done at compile time, you can update the compiler and update the scheduling/performance. Unfortunately, creating compilers for these systems was incredibly difficult, hence the failure of ix64/EPIC.
- wyldfire 9y ago
  Qualcomm makes a VLIW DSP called "Hexagon" used in their SoCs [1]. It's a pretty popular chip used in lots of phones. [1] https://en.wikipedia.org/wiki/Qualcomm_Hexagon#Code_sample https://en.wikipedia.org/wiki/Qualcomm_Hexagon#Code_sample
- puzzlingcaptcha 9y ago
  There also used to be the Transmeta processors which were x86 compatible and did the translation to VLIW in software (CMS - Code Morphing Software). I used to have a hp thin client with a Transmeta Efficeon where I installed Debian and it worked remarkably well for a 2004 processor, handily beating some Atoms and VIA Nanos in real-life workloads. Frankly I don't know what led to its demise.
RandomOpinion 9y ago
> Not that I can do anything about it, my conclusion over nearly 4 decades is that we have failed to take advantage of the increasingly denser silicon to make higher level machines, in particular machines that recognise the difference an instruction and a data element. That's basically the CISC concept (https://en.wikipedia.org/wiki/Complex_instruction_set_computing https://en.wikipedia.org/wiki/Complex_instruction_set_comput...) all over again. The problem still being: which instructions do you choose to implement in hardware and how do you make a compiler smart enough to recognize when to use them? Remember, CISC went out of style because all of those high level instruction weren't being used when processor manufacturers generated statistics on commonly used software.
- oldandtired 9y ago
  This is where the programmer or even compiler writer should have control, by allowing access to a micro-programmable base that supplies a standard set of instructions. The capability of adding instructions at need being under control of the machine administrator. For most tasks, this additional capability will not be needed, but for those who need to high optimisation, then they can do so with aplomb. Especially for those who are writing VM's for their respective high-level languages. As with anything, security of the hardware would need to be considered. One set of minicomputer hardware that I used to program on decades ago (Honeywell DPS6-92's) had a micro-programmable cpu. We didn't use it, as the base level hardware and associated software were sufficient for our needs. But I had heard that various organisations had incorporated their own instructions when needed. The choice of normal instructions can be quite small, but the ability to put in user defined instructions would allow certain models of thought to be tested and/or developed at a hardware level.
  - RandomOpinion 9y ago
    > ...allowing access to a micro-programmable base... What you're probably looking for is something like Forin's eMIPS (extensible MIPS) project that includes a block FPGA cells as part of the execution pipeline to allow creation of new instructions as needed. https://www.microsoft.com/en-us/research/project/emips/ https://www.microsoft.com/en-us/research/project/emips/
powera 9y ago
Have you heard about Mill Computing?
oldandtired 9y ago
I have managed to rummage around and found the article. It was actually in IEEE Micro May 1982, "A Unique Microprocessor Instruction Set" Dennis A Fairclough. The article looked at the statistical usage of instructions and placed them into 8 broad groups, Data Movement, Program Modifying, Arithmetic, Compare, Logical, Shift, Bit and I/O & Misc groups. The result of the analysis was as follows: For groups data movement and Program Modifying, 1 Instruction - MOVE [Cummulative usage 75%] For group Arithmetic, 4 Instructions - ADD, SUB, MULT, DIV [Cumulative usage 87.5%] For group Compare, 1 previous Instruction - SUB [Cumulative usage 93.75%] For group Logical, 3 Instructions - AND, OR, XOR [Cumulative usage 96.88%] For group Shift, 1 Instruction - SHIFT [Cumulative usage 98.44%] For group Bit, 1 Instruction - MOVEB [Cumulative usage 99.22%] For group I/O & Misc, depends on whether i/o is memory mapped or otherwise, so either 0 or 1 Instruction. Some possible extended instructions included INC, DEC, I/DBRC and MOVEM. The address fields (and in some cases additional flags) determine source and destination, etc. So, in relation to the VLIW question, the instruction length is determined more by the addressing modes allowed than by the specific instruction itself (which is encoded in say 4 bits).

adyavanapalli 9y ago

Can you please link that article?

oldandtired 9y ago
See my comment above.

djsumdog 9y ago

Are you talking about Very Long Instruction Words (VLIW)? IIRC, that's the concept of having the scheduling done in the compiler. Instead of the compiler spitting out op codes and operands, each part of the instruction space controls specific functional units. So if you stick something in the adder, the documentation might specify the next x instructions need to be nops so it can complete. The idea being if scheduling is done at compile time, you can update the compiler and update the scheduling/performance. Unfortunately, creating compilers for these systems was incredibly difficult, hence the failure of ix64/EPIC.

wyldfire 9y ago
Qualcomm makes a VLIW DSP called "Hexagon" used in their SoCs [1]. It's a pretty popular chip used in lots of phones. [1] https://en.wikipedia.org/wiki/Qualcomm_Hexagon#Code_sample https://en.wikipedia.org/wiki/Qualcomm_Hexagon#Code_sample
puzzlingcaptcha 9y ago
There also used to be the Transmeta processors which were x86 compatible and did the translation to VLIW in software (CMS - Code Morphing Software). I used to have a hp thin client with a Transmeta Efficeon where I installed Debian and it worked remarkably well for a 2004 processor, handily beating some Atoms and VIA Nanos in real-life workloads. Frankly I don't know what led to its demise.

RandomOpinion 9y ago

> Not that I can do anything about it, my conclusion over nearly 4 decades is that we have failed to take advantage of the increasingly denser silicon to make higher level machines, in particular machines that recognise the difference an instruction and a data element. That's basically the CISC concept (https://en.wikipedia.org/wiki/Complex_instruction_set_computing https://en.wikipedia.org/wiki/Complex_instruction_set_comput...) all over again. The problem still being: which instructions do you choose to implement in hardware and how do you make a compiler smart enough to recognize when to use them? Remember, CISC went out of style because all of those high level instruction weren't being used when processor manufacturers generated statistics on commonly used software.

oldandtired 9y ago
This is where the programmer or even compiler writer should have control, by allowing access to a micro-programmable base that supplies a standard set of instructions. The capability of adding instructions at need being under control of the machine administrator. For most tasks, this additional capability will not be needed, but for those who need to high optimisation, then they can do so with aplomb. Especially for those who are writing VM's for their respective high-level languages. As with anything, security of the hardware would need to be considered. One set of minicomputer hardware that I used to program on decades ago (Honeywell DPS6-92's) had a micro-programmable cpu. We didn't use it, as the base level hardware and associated software were sufficient for our needs. But I had heard that various organisations had incorporated their own instructions when needed. The choice of normal instructions can be quite small, but the ability to put in user defined instructions would allow certain models of thought to be tested and/or developed at a hardware level.
- RandomOpinion 9y ago
  > ...allowing access to a micro-programmable base... What you're probably looking for is something like Forin's eMIPS (extensible MIPS) project that includes a block FPGA cells as part of the execution pipeline to allow creation of new instructions as needed. https://www.microsoft.com/en-us/research/project/emips/ https://www.microsoft.com/en-us/research/project/emips/

powera 9y ago

Have you heard about Mill Computing?

oldandtired 9y ago

I have managed to rummage around and found the article. It was actually in IEEE Micro May 1982, "A Unique Microprocessor Instruction Set" Dennis A Fairclough. The article looked at the statistical usage of instructions and placed them into 8 broad groups, Data Movement, Program Modifying, Arithmetic, Compare, Logical, Shift, Bit and I/O & Misc groups. The result of the analysis was as follows: For groups data movement and Program Modifying, 1 Instruction - MOVE [Cummulative usage 75%] For group Arithmetic, 4 Instructions - ADD, SUB, MULT, DIV [Cumulative usage 87.5%] For group Compare, 1 previous Instruction - SUB [Cumulative usage 93.75%] For group Logical, 3 Instructions - AND, OR, XOR [Cumulative usage 96.88%] For group Shift, 1 Instruction - SHIFT [Cumulative usage 98.44%] For group Bit, 1 Instruction - MOVEB [Cumulative usage 99.22%] For group I/O & Misc, depends on whether i/o is memory mapped or otherwise, so either 0 or 1 Instruction. Some possible extended instructions included INC, DEC, I/DBRC and MOVEM. The address fields (and in some cases additional flags) determine source and destination, etc. So, in relation to the VLIW question, the instruction length is determined more by the addressing modes allowed than by the specific instruction itself (which is encoded in say 4 bits).