[bsder]

The dirty secret is: nobody cares because the ISA doesn't matter.

When programming a modern microcontroller, I regularly think: "Gee, I wish I had more pins." "Gee, I wish I had documentation on that peripheral." "Gee, I wish I had better tool support." or "Gee, I wish I had more RAM/Flash/MHz."

I never think "Gee, I wish I had a better ISA".

I applaud the effort to make an open microprocessor especially in light of the increasing efforts to put trusted module crap in our computers. However, this has no commercial advantage in any way other than that.

[renox]

> The dirty secret is: nobody cares because the ISA doesn't matter.

I disagree!! While normal operations don't matter, think about features like 'trap on integer overflow', if it was widespread in the popular ISAs we would have language which would use this semantic and as a result less bugs.

Another interesting feature could be Azul's Vega realtime GC support but I don't know if this requires a change of the ISA, or if it's just a MMU feature..

Hardware capabilities/segmentation would also require support in the ISA.

That said I agree with you that the RISC-V is just 'yet another ISA' which doesn't have interesting technical features, it's main feature is that it is open and you can implement it without paying someone for the privilege.

[bsder]

> While normal operations don't matter, think about features like 'trap on integer overflow', if it was widespread in the popular ISAs we would have language which would use this semantic and as a result less bugs.

You need to study history, son. :)

All of the ISA's from the 70's and early 80's HAD an overflow feature. It was wiped out when we jumped to 32-bit architectures because overflow was so much less common.

GC at the hardware level was, I believe, done by the Lisp Machine. However, standard RISC chips could run rings around it.

Modern ISA's aren't simply a bug in amber that solidified the mistakes of yesteryear never to be rectified. Modern ISA's have many features precisely to correct the mistakes made in the past.

[renox]

> All of the ISA's from the 70's and early 80's HAD an overflow feature.

Really? The first ISA I learned was the 6809 ISA, my memory is a bit fuzzy but I don't remember any 'trap on overflow' feature in the ISA.. Does the x86 has this?

Plus, if you believe that new language are always better than old language, it is you who need to better study history.

About GC at the hardware level: Lisp machine failed so what? There are different many ways to help supporting GCs.. Plus hardware GC wasn't the only feature of Lisp machines..

I don't get your point about "modern ISA" plus I'm not sure that you can lump x86-64 and ARMv8 ISAs in the same category even though both are 'modern ISAs'.

[bsder]

BVS/BVC -- same as the PDP11

Well, the concept of condition type "trap" didn't appear until deep pipelining. However, hardware very much supported condition codes. In fact, the reason why condition codes disappeared was because of deep pipelining--you had to wait for the full result in order to compute carry, overflow, etc.

However, I can tell you from painful personal experience that the 6809 ISA had an overflow condition code.

[lispm]

Lisp Machines had hardware support for GC. That does not mean the GC was a hardware function.

RISC machines were faster than the Lisp processors, but not at the time when both were actively developed and mostly for the smaller benchmarks. At the time RISC processors were appearing, several Lisp chips based on RISC were developed (SPUR, Symbolics, Xerox, ...). They never reached the market, mostly since the AI Winter already set in. Lisp Machine software was then ported as virtual machines to SUN SPARC (Xerox) and DEC Alpha (Symbolics).

[renox]

> All of the ISA's from the 70's and early 80's HAD an overflow feature.

All? The C was developed for the PDP11 which doesn't seem to have 'trap on overflow integer operations' like the MIPS has.

[bsder]

Yeah, all. Or so close as to be indistinguishable from all.

If I'm really being pedantic, overflow detection was probably more prevalent than two's complement arithmetic at one point.

Directly from the PDP11 ISA:

BVC/BVS -- branch on overflow set/clear

Y'all need to go refresh your memory/study some history before arguing about this more. :)

[renox]

And you'd better read before replying: I said trap on integer overflow, not branch on integer overflow. The former gives you overflow check 'for free', the latter reduce the code density, which impact the instruction cache, which can reduce the performance. And in the early days, performance was above everything else, CPU being so slow..

[krasin]

In this case, an open ISA would allow more stability over time. More over, once we have an open and widely adopted ISA, one can build an open microcontroller. After that, embedded developers will stop getting bad surprises when some specific microcontroller is being deprecated / out of stock and the whole board (and likely large parts of the firmware) has to be redesigned.

And you're right: an ISA don't matter. It could be ARM, AVR or OpenRISC / RISC-V, but it's very desirable to be stable and embeddable into a SoC without purchasing additional licenses.

[gioele]

> I never think "Gee, I wish I had a better ISA".

After programming with AltiVec, going back to MMX/SSE made me wish I had a better ISA.