Burroughs instruction streams are on byte boundaries, and had variable length instructions starting with 1 byte, including long ones for making useful literals
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.
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. "
> 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
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
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 :)
This is different from the 432 having opcodes that weren't a multiple of 8 bits, making decoding even more complicated than on x86.