The time has now come to show a concrete example of a modern CISC processor, taking as an example a new architecture, NEx64T, which is both a rewrite and an extension of the more emblazoned x86 and x64.

English: https://www.appuntidigitali.it/20820/nex64t-a-new-hope/
Italian: https://www.appuntidigitali.it/20783/nex64t-una-nuova-speranza/

@cdimauro

When do we get a simulator?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @cdimauro When do we get a simulator?

First I need a compiler, which is the hardest part.

I've took a look at the 68k's LLVM patches (because for many key aspects the structure of my ISA is more similar to our beloved processors family instead of x86/x64), but it's still huge and complex to understand and reuse (more here).

The LLVM Tutorial is very nice and explains a lot of things, showing how to start from the very beginning, but it still requires a lot of time to be "digested" and produce something concrete.

In short: it'll take long to have something usable (my spare time is limited, unfortunately).

@cdimauro

Would it not make more sense to start with an assembler? You said it's source compatible with x64, so you could either take an existing one and alter it to emit your object code or alternatively just implement enough of the x64 assembler syntax in python (for simplicity and rapidity) to be able to produce viable object code for execution.

Starting with a compiler and all of its associated complexity is just giving yourself a bigger reason not to.

My MC64K assembler is written in PHP because I didn't fancy spending a month writing it in C++ when I could be writing the interpreter.

Last edited by Karlos on 16-Nov-2023 at 07:39 AM.

_________________
Doing stupid things for fun...

@cdimauro
Good introduction. While 68k and x86-64 assembler may look similar and have similar performance potential, encodings are as different as night and day. You just started to scratch the surface of x86-64 encoding hell which may be some of the resistance to change. Anything new should be verified and documented which is an immense task.

https://www.unomaha.edu/college-of-information-science-and-technology/research-labs/_files/enumerating-x86-64-instructions.pdf Quote:

Although the intel/AMD 64-bit instruction set is large, it would seem that there would be a relatively simple / programmatically easy way to generate all of the instructions and from there, or in the process, to determine the number of bytes for each. Come to find out this task is surprisingly difficult. Even as recently as 2016 one could assume that “a formal semantics of the current 64-bit x86 ISA … would be readily available, but one would be wrong. In fact, the only published description of the x86-64 ISA is the Intel manual with over 3,800 pages written in an ad-hoc combination of English and pseudo-code”. ... Based on the breakout in Table 1, culled from the intel instruction set reference, we add up 822 instruction mnemonics. But Heule et. al. states that the current x86-64 design “contains 981 unique mnemonics and a total of 3,684 instruction variants”. However they do not specify which features are included in their count.

The 68k has a few ways of encoding each instruction while x86-64 has many. The paper above found 923,392,709 possible 6 byte encoding combinations already and an x86-64 instruction can be up to 15 bytes. Figure 1 at the bottom of the paper called "Partial Overview of x86-64 Decoding" gives a nice algorithmic flowchart of the decoding complexity. Then there is different behavior based on different processor state information and modes which is way more complex than it needs to be on x86(-64). It looks like a big mess that grows yet they have managed to keep it working in hardware and don't want to break it despite the growing decoding overhead and deteriorating code density.

@Karlos

Quote:

Karlos wrote: @cdimauro Would it not make more sense to start with an assembler? You said it's source compatible with x64, so you could either take an existing one and alter it to emit your object code or alternatively just implement enough of the x64 assembler syntax in python (for simplicity and rapidity) to be able to produce viable object code for execution. Starting with a compiler and all of its associated complexity is just giving yourself a bigger reason not to. My MC64K assembler is written in PHP because I didn't fancy spending a month writing it in C++ when I could be writing the interpreter.

You're right and that was (and still is: I haven't abandoned it) an idea.

The problem is that way I just translate x86/x64 instructions to the NEx64T and... that's it. I use no new features: no new addressing modes (pre/post inc/decrement, no data stride), no new registers (besides two which I've defined to keep compatibility with the "high" 8 bit registers and the more complex addressing modes), no binary/unary instructions using two/one source operand (and the destination), no mem-to-mem instructions.

I could implement a better peophole optimizer (the current one works only on two instructions, essentially) by implementing an assembler, taking a look at blocks of instructions to gain something using at least some new features.

I still have to think about it.


@matthey

Quote:

matthey wrote: @cdimauro Good introduction. While 68k and x86-64 assembler may look similar and have similar performance potential, encodings are as different as night and day. You just started to scratch the surface of x86-64 encoding hell which may be some of the resistance to change. Anything new should be verified and documented which is an immense task.

Well, it was already an hard work mapping all x86/x64 instructions to one (or more, in some cases) NEx64T.
Quote:

https://www.unomaha.edu/college-of-information-science-and-technology/research-labs/_files/enumerating-x86-64-instructions.pdf Quote: Although the intel/AMD 64-bit instruction set is large, it would seem that there would be a relatively simple / programmatically easy way to generate all of the instructions and from there, or in the process, to determine the number of bytes for each. Come to find out this task is surprisingly difficult. Even as recently as 2016 one could assume that “a formal semantics of the current 64-bit x86 ISA … would be readily available, but one would be wrong. In fact, the only published description of the x86-64 ISA is the Intel manual with over 3,800 pages written in an ad-hoc combination of English and pseudo-code”. ... Based on the breakout in Table 1, culled from the intel instruction set reference, we add up 822 instruction mnemonics. But Heule et. al. states that the current x86-64 design “contains 981 unique mnemonics and a total of 3,684 instruction variants”. However they do not specify which features are included in their count. The 68k has a few ways of encoding each instruction while x86-64 has many. The paper above found 923,392,709 possible 6 byte encoding combinations already and an x86-64 instruction can be up to 15 bytes. Figure 1 at the bottom of the paper called "Partial Overview of x86-64 Decoding" gives a nice algorithmic flowchart of the decoding complexity. Then there is different behavior based on different processor state information and modes which is way more complex than it needs to be on x86(-64). It looks like a big mess that grows yet they have managed to keep it working in hardware and don't want to break it despite the growing decoding overhead and deteriorating code density.

Great paper, thanks! I think that I'll use as a reference on the next article.

NEx64T doesn't suffer at all of that: it has no prefixes and only some bigger opcodes for extending the functionalities of the base instructions. Plus, instructions are much better grouped / organized.