Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V: An Open Standard for SoCs

eetimes.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: RISC-V: An Open Standard for SoCs

#21

Post by bsder »

renox wrote: post #16
bsder wrote: post #8

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 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…

> 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.

Re: RISC-V: An Open Standard for SoCs

#22

Post by lispm »

bsder wrote: post #21
renox wrote: post #16

Earlier quoted context omitted.

> 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…

> 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. G…

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).

Re: RISC-V: An Open Standard for SoCs

#23

Post by renox »

bsder wrote: post #21
renox wrote: post #16

Earlier quoted context omitted.

> 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…

> 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. G…

> 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'.

Re: RISC-V: An Open Standard for SoCs

#24

Post by renox »

bsder wrote: post #21
renox wrote: post #16

Earlier quoted context omitted.

> 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…

> 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. G…

> 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.

Re: RISC-V: An Open Standard for SoCs

#25

Post by bsder »

renox wrote: post #23
bsder wrote: post #21

Earlier quoted context omitted.

> 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. G…

> 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? The…

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.

Re: RISC-V: An Open Standard for SoCs

#26

Post by bsder »

renox wrote: post #24
bsder wrote: post #21

Earlier quoted context omitted.

> 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. G…

> 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.

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. :)

Re: RISC-V: An Open Standard for SoCs

#27

Post by renox »

bsder wrote: post #26
renox wrote: post #24

Earlier quoted context omitted.

> 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.

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. :)

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..
Post reply on HN