bob wrote:It is simply what you get when you keep hacking on an instruction set to add new features.
The customers have decided that they don't want to throw away all the software they already paid for. That's why backwards compatibility won, because it addressed the needs of the paying customers.
But none of that backward-compatibility for a puny chip would have been necessary if IBM hadn't compromised their brand by choosing the Intel 8088 for reasons of expediency. IBM originally wanted the more natural choice of Motorola 68000 since its architecture/assembly was somewhat similar to their mainframe s360 architecture. (The Motorola even has some built-in BCD instructions.) But Motorola manufacturing was not quite ready for the volume IBM needed, so they went with the drastically not-forward-looking but highly available 8088/16 chips, saddling the development community with a scrawny architecture basically forever.
Only question is, who wants to do that? No speed savings to fetch less than an 8 byte value, a penalty in fact... Causes lots of overhead on the network which is big-endian in data transmission (hence the hton functions in the network library...
bob wrote:It is simply what you get when you keep hacking on an instruction set to add new features.
The customers have decided that they don't want to throw away all the software they already paid for. That's why backwards compatibility won, because it addressed the needs of the paying customers.
But none of that backward-compatibility for a puny chip would have been necessary if IBM hadn't compromised their brand by choosing the Intel 8088 for reasons of expediency. IBM originally wanted the more natural choice of Motorola 68000 since its architecture/assembly was somewhat similar to their mainframe s360 architecture. (The Motorola even has some built-in BCD instructions.) But Motorola manufacturing was not quite ready for the volume IBM needed, so they went with the drastically not-forward-looking but highly available 8088/16 chips, saddling the development community with a scrawny architecture basically forever.
I completely agree, and remember when this issue was being discussed. I was teaching M6800 and then M68000 back in the day. Motorola had this "book" they sold which was a fat ring binder with a 68000 single-board machine in the binder. Was really a nice architecture, matched machines like the xerox, /360 or /370, Dec, etc. IE 16 general purpose registers, single memory operand instructions (which the /360 subverted with the mvc type instructions that were slow as christmas).
And here we are. Good processors, horrible instruction set architecture.
However, ALL of the 68k machines were closed ecosystems, unlike the IBM PC. Consequence: upgrade to a new processor, which in itself was difficult or expensive enough, and then the software would stop working because it all relied on the standardised hardware. Not only games, but also many applications. That set a negative incentive for innovation. Don't buy newer stuff or it will stop working. That's why 030 machines were not widespread, and nobody had a 040 one.
Meanwhile in the Intel ecosystem, the main issue was thoughtless game programmers who used fixed delay loops, making games unplayable with faster CPUs. But auto-calibrating delay loops against the RTC was no rocket science, and once that spread, you could safely buy something faster, and things still worked, only better. And everytime you bought new stuff, Intel made money that they put into cranking out ever faster CPUs. It became a self-accelerating cycle.
bob wrote:Only question is, who wants to do that? No speed savings to fetch less than an 8 byte value, a penalty in fact... Causes lots of overhead on the network which is big-endian in data transmission (hence the hton functions in the network library...
I found a use case for this in my current project. Certainly it's not about speed.
Lots of overhead? You can't be possibly serious... bswap is fast as mov and this only covers packet header, not the data you send.
Considering what you have to do on the CPU part to just send a packet, it boils down to nothing, certainly not anything you could even measure.
mhull wrote:saddling the development community with a scrawny architecture basically forever.
Well, no. The last true x86 architecture was the 486. After that, we still have the external x86 instruction set, but not the architecture; internally, modern x86 CPUs are something entirely different. And nobody cares for the external instruction set. Already 10 years ago, the actual x86 related part of the CPU's die was neglectable.
What this variable length CISC ISA does is actually a sort of compression, and since CPU speed has increased way more than memory speed, this is even a good thing, because it's a better use of the CPU caches.
mhull wrote:saddling the development community with a scrawny architecture basically forever.
Well, no. The last true x86 architecture was the 486. After that, we still have the external x86 instruction set, but not the architecture; internally, modern x86 CPUs are something entirely different. And nobody cares for the external instruction set. Already 10 years ago, the actual x86 related part of the CPU's die was neglectable.
What this variable length CISC ISA does is actually a sort of compression, and since CPU speed has increased way more than memory speed, this is even a good thing, because it's a better use of the CPU caches.
Then why does the open source RISC V not resemble the Intel model? The registers look more like, well, IBM s/360, not the Intel/AMD kluge. I think this illustrates the point being made, that the peculiar Intel μC wasn't the best way forward to begin with.
Ras wrote:What this variable length CISC ISA does is actually a sort of compression, and since CPU speed has increased way more than memory speed, this is even a good thing, because it's a better use of the CPU caches.
The uniform instruction length of RISC turned out to be not an advantage and perhaps a disadvantage, but I don't think the x86-64 instruction set is a good example of how to encode instructions efficiently.
