Saw some discussions about ISA's in this forum and this might be interesting to some of you. What do you think?

https://forwardcom.info/

@AmigaNoob

Amiga 68K is about retro legacy compatibility.

_________________
Core i9-9900K, DDR4-3800 32 GB RAM, GeForce RTX 3080 Ti
Ryzen 9 3900X, DDR4-3200 32 GB RAM, GeForce RTX 2080 Ti
Amiga 1200 (rev 1D1, KS 3.2, TF1260, 68060 @ 63 Mhz, 128 MB)
Amiga 500 (rev 6A, KS 3.2, 68K 50Mhz, 12 MB RAM)

@Hammer

Yes, and? This was correctly posted under general technology.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@AmigaNoob Quote:

AmigaNoob wrote: Saw some discussions about ISA's in this forum and this might be interesting to some of you. What do you think? https://forwardcom.info/

I know and I've already analyzed it some years ago, but this project seems to be stuck and didn't moved.

Anyway, I don't agree with this Agner's statement:
The ForwardCom instruction set is neither RISC nor CISC, but a new paradigm with the advantages of both.
ForwardCom IS clearly a CISC ISA, and definitely not a RISC.

Regarding the ISA per se I don't think that it can get any gain compared to current RISC or CISC designs. It's neither simple nor complicated, however I think that its biggest problems is that it will surely have a poor code density due to the 32-bit / 4 bytes instructions sizes & alignment.

It has no "compact" instructions, and despite having the possibility to directly reference an immediate for constant, the code size for its software will take huge space.

There isn't yet data about it, but it's my strong feeling while taking a look at its instructions and opcode formats.

By comparison, my NEx64T ISA has a big part of instructions which are 16-bit in size, and this improved the code density compared to x86 and x64 (especially), with evident advantages. And this using just a small part of my ISA: both code size and number of executed instructions can improve by using the new features that I've introduced.

@AmigaNoob

I think x86, ARM and RISC-V (all offers both 32-bit and 64-bit options) ought to be enough. The capital and work needed to create a new architecture is monumental. And it serves no point.

@TRIPOS

Can’t argue against progress, someone will always come up with some bright idea. useless or not.

Last edited by NutsAboutAmiga on 17-Oct-2021 at 11:37 AM.
Last edited by NutsAboutAmiga on 17-Oct-2021 at 11:36 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@TRIPOS

Quote:

TRIPOS wrote: @AmigaNoob I think x86, ARM and RISC-V (all offers both 32-bit and 64-bit options) ought to be enough. The capital and work needed to create a new architecture is monumental. And it serves no point.

The capital is primarily needed for the tools / infrastructure for supporting a new architecture.

If you don't have a modern (optimizing) compiler (plus debugger, plus standard library, etc.) for your ISA, then you're out of the market.

Even writing the backend for a good compiler requires a lot of effort...

cdimauro Quote:

Regarding the ISA per se I don't think that it can get any gain compared to current RISC or CISC designs. It's neither simple nor complicated, however I think that its biggest problems is that it will surely have a poor code density due to the 32-bit / 4 bytes instructions sizes & alignment. It has no "compact" instructions, and despite having the possibility to directly reference an immediate for constant, the code size for its software will take huge space. There isn't yet data about it, but it's my strong feeling while taking a look at its instructions and opcode formats.

I expect the ForwardCom ISA code density to be poor also. It is 16 bit and 48 bit instructions which improve code density the most. The 4 byte alignment advantage is not worth it. A 16 bit base encoding for a variable length ISA like the 68k uses provides the best compromise between code density and code alignment efficiency. There is a reason why it has been copied so much.

cdimauro Quote:

By comparison, my NEx64T ISA has a big part of instructions which are 16-bit in size, and this improved the code density compared to x86 and x64 (especially), with evident advantages. And this using just a small part of my ISA: both code size and number of executed instructions can improve by using the new features that I've introduced.

Yes, x86(-64) wasted too much of the encoding space on 8 bit instructions which resulted in new instructions being excessively long. With an 8 bit base variable length encoding, it is better to start with all or nearly all instructions being 16 bit as you suggest and as also used by the Cast BA2 ISA. It is probably possible to achieve a little better code density than a 16 bit variable length encoding by doing this at the expense of less efficient code alignment most obvious in instruction decoding.