3 ms·

But it hasn't been made. Isn't that the point? Assembly maps very closely to actual hardware instructions/opcodes

by FatalLogic 5y ago

pjmlp 5y ago
Not on x86 it doesn't.
- FatalLogic 5y ago
  Well, nonetheless, it's the lowest level you can code at, isn't it?
  - pjmlp 5y ago
    Same applies to any bytecode format, when an hardware implementation for it happens to exist. It was how Xerox PARC workstations worked, the bytecode of Interlisp-D, Mesa, Mesa/Cedar, Smalltalk worked, with microcode interpreter loaded on boot for them. How Lillith (Modula-2) and Cedar (Oberon) workstations worked, with hardware implementation of their bytecode formats. How some Java CPUs like Jazelle and JavaOS worked. How Pascal USCD worked on Constellation OS by Corvus Systems. How Burroughs B5500 mainframes worked, with ESPOL/NEWP intrinsics, still being shipped by Unisys nowadays on a completely unrelated hardware form. I certainly can dig out a couple of other examples.
    - FatalLogic 5y ago
      This is interesting, thanks, but I don't understand how it supports the refutation you made about x86, which is what I was responding to
      - pjmlp 5y ago
        Modern x86 is just bytecode for a microcode only Intel has the tooling available.
        FatalLogic 5y ago
        I understand that. Then this is probably just a disagreement about the definition of 'Assembly'. I define Assembly as the lowest level that is user-accessible. I think you would say that's a rather arbitrary division in the case of x86, when there is a sophisticated microcode language underneath it?
        pjmlp 5y ago
        Yes, history is full of bytecode formats at any given point have gotten hardware implementation for them. In some platforms they are even the only kind of format for executables and raw Assembly is forbidden to any userspace application, e.g. IBM i (nee AS/400) TIMI environment, where raw machine code is only available to the kernel, in the POSIX subsystem or special binaries produced via the Metal C compiler.

But it hasn't been made. Isn't that the point? Assembly maps very closely to actual hardware instructions/opcodes

pjmlp 5y ago

Not on x86 it doesn't.

FatalLogic 5y ago
Well, nonetheless, it's the lowest level you can code at, isn't it?
- pjmlp 5y ago
  Same applies to any bytecode format, when an hardware implementation for it happens to exist. It was how Xerox PARC workstations worked, the bytecode of Interlisp-D, Mesa, Mesa/Cedar, Smalltalk worked, with microcode interpreter loaded on boot for them. How Lillith (Modula-2) and Cedar (Oberon) workstations worked, with hardware implementation of their bytecode formats. How some Java CPUs like Jazelle and JavaOS worked. How Pascal USCD worked on Constellation OS by Corvus Systems. How Burroughs B5500 mainframes worked, with ESPOL/NEWP intrinsics, still being shipped by Unisys nowadays on a completely unrelated hardware form. I certainly can dig out a couple of other examples.
  - FatalLogic 5y ago
    This is interesting, thanks, but I don't understand how it supports the refutation you made about x86, which is what I was responding to
    - pjmlp 5y ago
      Modern x86 is just bytecode for a microcode only Intel has the tooling available.
      - FatalLogic 5y ago
        I understand that. Then this is probably just a disagreement about the definition of 'Assembly'. I define Assembly as the lowest level that is user-accessible. I think you would say that's a rather arbitrary division in the case of x86, when there is a sophisticated microcode language underneath it?
        pjmlp 5y ago
        Yes, history is full of bytecode formats at any given point have gotten hardware implementation for them. In some platforms they are even the only kind of format for executables and raw Assembly is forbidden to any userspace application, e.g. IBM i (nee AS/400) TIMI environment, where raw machine code is only available to the kernel, in the POSIX subsystem or special binaries produced via the Metal C compiler.