4 ms·

There's something about this that gives the impression of an ISA that was developed in simulation without any real regard for hardware and then just tossed over

by djur 4y ago

There's something about this that gives the impression of an ISA that was developed in simulation without any real regard for hardware and then just tossed over the wall to be realized in silicon. I'm particularly baffled by instructions not being byte-aligned. Is there any successful processor that takes this "stream of bits" approach?

Taniwha 4y ago
It's actually not all that different from the Burroughs large systems architectures (B5000/B6700/A-series) which were initially released in the late 60s ... stack machines, similar descriptor based memory structures, tagged memory etc etc Burroughs instruction streams are on byte boundaries, and had variable length instructions starting with 1 byte, including long ones for making useful literals
- pjmlp 4y ago
  And still being sold by Unisys to this day.
  - dfox 4y ago
    AFAIK what is sold today by Unisys are essentially preconfigured emulators running on what is otherwise normal Xeon servers.
    - pjmlp 4y ago
      Naturally Unisys ClearPath MCP isn't running the same hardware as Burrough Large Systems from 1961. They don't need emulators, as Burroughs was one of the first bytecode based OSes, but I am not sure how it looks in detail.
      - skissane 4y ago
        > They don't need emulators, as Burroughs was one of the first bytecode based OSes, but I am not sure how it looks in detail. Do you have a source for that claim? I don't think that's true.
        pjmlp 4y ago
        That Burroughs was one of the first bytecode based OSes? https://en.wikipedia.org/wiki/Burroughs_Large_Systems https://en.wikipedia.org/wiki/Burroughs_Large_Systems And thanks for making having another look into it, as it clearly points out there are emulators and native implementations (MCP CMOS), "These machines were the Libra 100 through the Libra 500, With the Libra 590 being announced in 2005. Later Libras, including the 590, also incorporate Intel Xeon processors and can run the Burroughs large systems architecture in emulation as well as on the MCP CMOS processors. It is unclear if Unisys will continue development of new MCP CMOS ASICs. "
        skissane 4y ago
        > That Burroughs was one of the first bytecode based OSes? > https://en.wikipedia.org/wiki/Burroughs_Large_Systems https://en.wikipedia.org/wiki/Burroughs_Large_Systems I don't know how you get that from that article, because I can't see the word "bytecode" anywhere in it. What text in that article do you think supports your contention? > And thanks for making having another look into it, as it clearly points out there are emulators and native implementations (MCP CMOS), The same article contains this sentence: "Unisys stopped producing the hardware in the early 2010s, and the operating system is now run under emulation" So there was proprietary hardware, up to about 10 years ago, but nowadays it is all standard x86-64 servers running their software emulator
        kjs3 4y ago
        We run Clearpath at $DAYJOB. I haven't cracked open one of them to look myself, but the folks running them have told me they're pretty much bog standard, high-end x86-64 servers running a Unisys VM. No proprietary hardware.
        fsckboy 4y ago
        > I don't know how you get that from that article, because I can't see the word "bytecode" anywhere in it. What text in that article do you think supports your contention? not sure if you're hung up on the word "byte", but it says the architecture is a stack machine and that's what p-code/bytecode interpreters emulate, so whether it's byte codes or word codes, it's essentially the same thing
flohofwoe 4y ago
AFAIK there's a 'bit-addressable' extension for ARM, but I lack the google-fu to search for it (I guess this only applies to loading and storing data, not 'arbitrary width instructions') For the data load/store case, if you go with the (high-level) idea that bytes are nothing special anymore (because cache line width is the new word width), and instead you have arbitrary width integers (like Zig for instance), it would also make sense to have 'bit granularity pointers'. All you'd need is to move a regular pointer 3 bits to the left (which should be ok because the upper bits are wasted anyway). IMHO this would make a lot of sense from a system programming language PoV, but I guess the hardware guys can think of a couple of reasons to object :)
- rep_lodsb 4y ago
  Bit-addressable data has been done in at least one other architecture: https://en.wikipedia.org/wiki/TMS34010 https://en.wikipedia.org/wiki/TMS34010 This is different from the 432 having opcodes that weren't a multiple of 8 bits, making decoding even more complicated than on x86.
  - kjs3 4y ago
    The Intel 8051 can do limited bit level addressing. It's restricted to a specific 16-byte region in low memory, which it makes it different than either the 432 or 34010.
maldev 4y ago
Stream of bits really simplifies it. If you read the intel documentation there's a nice diagram that explains the logic. Effectively you can view it as a object oriented, or grouping mechanism. If you look at instructions and prefixes. It effectively goes. PREFIX-EXTENSION(Ala AVX-256)-INSTRUCTION-ARG1-...-ARGN-PostFix.

by djur 4y ago

Taniwha 4y ago

It's actually not all that different from the Burroughs large systems architectures (B5000/B6700/A-series) which were initially released in the late 60s ... stack machines, similar descriptor based memory structures, tagged memory etc etc Burroughs instruction streams are on byte boundaries, and had variable length instructions starting with 1 byte, including long ones for making useful literals

pjmlp 4y ago
And still being sold by Unisys to this day.
- dfox 4y ago
  AFAIK what is sold today by Unisys are essentially preconfigured emulators running on what is otherwise normal Xeon servers.
  - pjmlp 4y ago
    Naturally Unisys ClearPath MCP isn't running the same hardware as Burrough Large Systems from 1961. They don't need emulators, as Burroughs was one of the first bytecode based OSes, but I am not sure how it looks in detail.
    - skissane 4y ago
      > They don't need emulators, as Burroughs was one of the first bytecode based OSes, but I am not sure how it looks in detail. Do you have a source for that claim? I don't think that's true.
      - pjmlp 4y ago
        That Burroughs was one of the first bytecode based OSes? https://en.wikipedia.org/wiki/Burroughs_Large_Systems https://en.wikipedia.org/wiki/Burroughs_Large_Systems And thanks for making having another look into it, as it clearly points out there are emulators and native implementations (MCP CMOS), "These machines were the Libra 100 through the Libra 500, With the Libra 590 being announced in 2005. Later Libras, including the 590, also incorporate Intel Xeon processors and can run the Burroughs large systems architecture in emulation as well as on the MCP CMOS processors. It is unclear if Unisys will continue development of new MCP CMOS ASICs. "
        skissane 4y ago
        > That Burroughs was one of the first bytecode based OSes? > https://en.wikipedia.org/wiki/Burroughs_Large_Systems https://en.wikipedia.org/wiki/Burroughs_Large_Systems I don't know how you get that from that article, because I can't see the word "bytecode" anywhere in it. What text in that article do you think supports your contention? > And thanks for making having another look into it, as it clearly points out there are emulators and native implementations (MCP CMOS), The same article contains this sentence: "Unisys stopped producing the hardware in the early 2010s, and the operating system is now run under emulation" So there was proprietary hardware, up to about 10 years ago, but nowadays it is all standard x86-64 servers running their software emulator
        kjs3 4y ago
        We run Clearpath at $DAYJOB. I haven't cracked open one of them to look myself, but the folks running them have told me they're pretty much bog standard, high-end x86-64 servers running a Unisys VM. No proprietary hardware.
        fsckboy 4y ago
        > I don't know how you get that from that article, because I can't see the word "bytecode" anywhere in it. What text in that article do you think supports your contention? not sure if you're hung up on the word "byte", but it says the architecture is a stack machine and that's what p-code/bytecode interpreters emulate, so whether it's byte codes or word codes, it's essentially the same thing

flohofwoe 4y ago

AFAIK there's a 'bit-addressable' extension for ARM, but I lack the google-fu to search for it (I guess this only applies to loading and storing data, not 'arbitrary width instructions') For the data load/store case, if you go with the (high-level) idea that bytes are nothing special anymore (because cache line width is the new word width), and instead you have arbitrary width integers (like Zig for instance), it would also make sense to have 'bit granularity pointers'. All you'd need is to move a regular pointer 3 bits to the left (which should be ok because the upper bits are wasted anyway). IMHO this would make a lot of sense from a system programming language PoV, but I guess the hardware guys can think of a couple of reasons to object :)

rep_lodsb 4y ago
Bit-addressable data has been done in at least one other architecture: https://en.wikipedia.org/wiki/TMS34010 https://en.wikipedia.org/wiki/TMS34010 This is different from the 432 having opcodes that weren't a multiple of 8 bits, making decoding even more complicated than on x86.
- kjs3 4y ago
  The Intel 8051 can do limited bit level addressing. It's restricted to a specific 16-byte region in low memory, which it makes it different than either the 432 or 34010.

maldev 4y ago

Stream of bits really simplifies it. If you read the intel documentation there's a nice diagram that explains the logic. Effectively you can view it as a object oriented, or grouping mechanism. If you look at instructions and prefixes. It effectively goes. PREFIX-EXTENSION(Ala AVX-256)-INSTRUCTION-ARG1-...-ARGN-PostFix.