Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 7:42 pm

I guess if you are adding huge arrays then the biggest time suck is reading and writing them to memory. When you step outside of what you have in the cache you are an order of magnitude slower. Perhaps even on a 64 bit machine one might as well do the addition 32 bits at a time and fish the carry from the 64 bit result.
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 8:18 pm

Yes it is true that on a modern 32 bit ARM a 64-bit add (two instructions) is as fast as a 32-bit add (single instruction) (thanks to our multple issue pipeline), so long as other code is correctly interleaved between the two adds (nice thing about ARM is you can do that even when you care about the carry).

99% of CPU archetecures since the early 1970's have used 2 complement math, and had overflow and carry. You just mentioned another strike against RISC V for me (part of why I had not yet done anything with RISC V is not figuring out how to detect such things). Designers realized the importance of these things, as well as the fact that there are very good reasons to allow math to roll over (especially when dealing with values larger than fit in registers).

Unfortunately most high level languages do not support this, even though it is extremely rare to find a CPU that does not, and those that do not have not survived for good reason.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4769
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 8:42 pm

ARM started the trend :(

Intel hardware correctly sets the overflow flag for all operations and for all sizes 8-bit, 16-bit, 32-bit, and 64-bit for
all of add, subtract, multiply and divide (INT_MIN / -1)

ARM sets the overflow flag only for 32-bit add and subtract.

RISC V doesn't set any flags.

I guess RISC is about replacing clever logic with extra software.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 8:45 pm

Heater wrote:
Sat Dec 01, 2018 7:42 pm
I guess if you are adding huge arrays then the biggest time suck is reading and writing them to memory. When you step outside of what you have in the cache you are an order of magnitude slower. Perhaps even on a 64 bit machine one might as well do the addition 32 bits at a time and fish the carry from the 64 bit result.
Yes it is a little bit more time on memory access, though not as bad as you may think. We do something like this:

Code: Select all

ALIGN 64, 4
   LDMFA R8!, {R0-R3}           ;First source array point into by R8.
.addlp
   ADDS  R4, R4,  #1            ;Restore the carry flag. 
   LDMFA R9!, {R4-7}           ;Second source array point into by R9.

   ADDS  R0, R0, R4
   ADDCS R1, R1, R5
   ADDCS R2, R2, R6
   ADDCS R3, R3, R7

   STMFA  R10!, {R0-R3}         ;R10 points into the sum array.
   MVNC   R4, #2                ;Preserve the carry flag, because the next op uses it.
   MOVC   R4, R4 ASR#1          ;   We put largest positive value in if there is carry.
   LDMFA R8!, {R0-R3}           ;First source array point into by R8.
   SUBS  R11,  R11, #1           ;R11 is a down counter giving 128bit elements to add.
   BNZ   addlp
.endadd

and the result is fairly good about having enough time between each access to reduce the effect of accessing memory. Note that this loop is under 16 instructions and that it is set up on a 64 byte boundry. Yes this is far from the most optimal, though it should give the idea. The bus is 128-bits wide in most cases today (including the RPi), thus the use of four registers at a time.


NOTE: Above code was typed from my brain into this post, has not been tested and may contain errors.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 9:29 pm

When we are taking about optimizing code it's better to present tested, working examples.

When we are talking about optimizing code that operates on a lot of data and the effects of cache misses are significant it gets a lot more complex to compare.

My claim is that if you have a data set much bigger than your cache size, and if it takes an order of magnitude more time to access data outside your cache than in it, as is typical, then it pretty much does not matter how you micro-optimize the instructions operating on your in cache data.

I first realized this a over a decade ago. I had a recursive FFT algorithm that was much slower than the regular nested loop FFT. Except I was amazed to find that the recursive FFT started to become the faster option when the sample set got over a megabyte or two.
Memory in C++ is a leaky abstraction .

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 9:32 pm

DavidS,
99% of CPU archetecures since the early 1970's have used 2 complement math, and had overflow and carry.
Yes. It's great that we have all homed in on something in common. And 2 two's comp makes a lot of sense.
You just mentioned another strike against RISC V for me (part of why I had not yet done anything with RISC V is not figuring out how to detect such things).
I presume you are talking about that missing flags in RISC V.

Well, not so fast there. The designers or RISC V, Patterson and co, have been studying the problem of designing an efficient instruction set architecture for three or four decades. They would not have dropped such a significant thing as carry/overflow/zero flags on a whim. No, those flags and the instructions that use them are missing from the ISA specification for a reason.

OK, that is not a very scientific argument of me, but consider: C and other high level languages have no concept of carry/overflow/zero flags. So why bother including them in the instruction set definition? It just complicates the architecture for little or no gain.
...Designers realized the importance of these things, ...
The claim here, in the RISC V world, is that CPU designers did not realize that these flags, and the instructions that use them, are not important!
...as well as the fact that there are very good reasons to allow math to roll over...
Yes indeed, I agree. A lot of code I have written has depended on roll over behavior. Despite what I said above about it being an arithmetic disaster.
Unfortunately most high level languages do not support this, even though it is extremely rare to find a CPU that does not, and those that do not have not survived for good reason.
RISC V will survive and thrive. Precisely because high level languages do not need those flags.

My personal take on this is that things like carry/overflow flags and the instructions that use them are included in instruction sets as a convenience to assembler programmers. Rather like the DAA instruction existed in Intel 8080 to make BCD maths easier for assembler programmers. DAA existed as AAA in the x86 instruction set even though no one used it for two decades or more. It was finally removed in AMD's 64 bit version of x86.

Similarly RISC V removes those redundant flags today.

If you suspect this is not an efficient instruction set design please spend half an hour watching this guys presentation, he has taken time to measure x86 vs ARM vs RISC V. 32 and 64 bit: https://www.youtube.com/watch?v=Ii_pEXKKYUg
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 9:49 pm

Thanks for linking something that is going to require me to go here on my phone, why does everyone link youtube.

Though I have a tested version of the code (not heavily, though quickly tested). And you can not do it without flags.

Code: Select all

ALIGN 64, 8
   MOV    R4, #0
   LDMFA  R8!, {R0-R3}        ;R8 points into first source.

.addlp
   ADD    R4, R4, #1
   LDMFA  R9!, {R4-R7}        ;R9 points into other source.

   ADDCSS R0, R0, R4
   ADDCSS R1, R1, R5
   ADDCSS R2, R2, R6
   ADDCSS R2, R2, R7

   STMFA  R10!, {R0-R3}       ;R10 points into sum.
   MOVCS  R4, #&7FFFFFFF      ;Preserve carry.
   SUBS   R11, R11, #1        ;R11 is the count of 128 bit ellements to add.
   LDMFA  R8!, {R0-R3}
   BNE    addlp
I am terrible about getting it correct when typing into a furum post, though it comes natural in a text editor.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4769
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 9:57 pm

Heater wrote:
Sat Dec 01, 2018 9:32 pm
My personal take on this is that things like carry/overflow flags and the instructions that use them are included in instruction sets as a convenience to assembler programmers. Rather like the DAA instruction existed in Intel 8080 to make BCD maths easier for assembler programmers. DAA existed as AAA in the x86 instruction set even though no one used it for two decades or more. It was finally removed in AMD's 64 bit version of x86.

Similarly RISC V removes those redundant flags today.
The thing about the x86 BCD instructions was that no one used them anymore. So was easy to remove them to make more opcode space available.

I did a quick check on some compiler output.
Just over 20% of the instructions are conditional jumps. That's not including all the setcc, adc, sbb etc etc instructions.
Clearly not redundant.

I'll have to watch the video to learn about this new revolution in computer architecture !

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 9:59 pm

Flags are moste definitely a need, otherwise you need a more complex HW implementation to deal with things like conditional execution (even if only done only for branching, like some CPU's that we all know).

Without flags, that are updated as a natural side effect of 2 complement ALU operations (and others) (and may be dissabled for update), you need circuits to determine the current state of values as an extra, this is difficult to do without adding to circuit propagation, and even if you can do it without the hit on propagation you still have added complexity for no gain.

Not to mention that compiler optimizations make heavy use of flags.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:13 pm

Actually as we move further from the common use of assembly language the use of flags and conditionals that are based on flag values is being seen as more important to CPU design in order to improve the optimization of compiled languages.

On the IntEl side we only had conditional branches through the 80486, with the 80586 AKA Pentium was added the MOVcc group of instructions explicitly to improve compiler optimization (though still over limited the registers). Since then even more conditional instructions have been added to the x86 and AMD64 (sometimes miss called IA64 [intel licensed it from AMD, like AMD licensed the 32/16 bit ISA from Intel]), all to imporve support for compilers (same reason there are more registers in the AMD64 arch than the IA32/16 Archs). I think it would be a good lesson on why the world is moving away from CISC if noob programmers were at some point early on taught IA32 assembly (including how to get into PMODE and survive once there).

The ARM has always been an easy target to optimize for from the perspective of compiler writers, because it lines up with the HLL's so well. Unfortunately some of that has not been taken advantage of very well do to the efforts of optimizing for 80x86 CPU's and M680x0 CPU's for so many years by the majority (what is an archane art for the x86 is not very hard for ARM, largely because of every instruction being conditional, oops AARCH64 dropped the ball).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4769
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:14 pm

I have just twigged how RISCV works without flags.

ARM has some instructions that test and jump in one.

cbz reg, offset // jump if reg is zero and cbnz (conditional branch if zero)
tbz reg, #31, offset // jmp not negative (test bit and jump if zero - 31 is the sign bit)
tbnz reg, #31, offset // jmp if negative

I assume RISC V has just extended that ???

Edit: no that cant be right. zero is a state. overflow is not
Last edited by jahboater on Sat Dec 01, 2018 10:24 pm, edited 1 time in total.

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:22 pm

DavidS,

I hate the idea that everything is now getting concentrated to Youtube. That is to say Google. That cannot be good in the long run. That is not any kind of "cloud", that is a centralized server owned by a monopoly. Sorry, there is not much I can do about it except shout to the clouds like the old man that I am.

I have no idea what you mean about the phone. I have modern day "smart" phones. I never use them to watch video. I prefer the comfort of my ancient PC's or laptops.
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:29 pm

Put another way, just because great minds think something may work better, does not mean it will.

Does anyone remember the MOS6502 8-Bit CPU? Ok do you also remember the i8086, and the M68000?

Well when the M68000 came out it was slower than an equally clocked MOS6502. Yes the 68000 was a 32 bit CPU (with a 16 bit external bus), though it took too many cycles to do a single op, so the 6502 could often beat it for many 16-bit and 32-bit operations while using 8-bit math. Now the 680x0 series did evolve to become the better of the CISC CPU's, though that is ancient history.

Does anyone remember the many different 16 core 16-bit CISC CPU's that came out in the early 1980's (I think some may have been older than that), and how they failed because there implementation was un-tollarably slow.

Examples of the 'better' 'more educated' engineers failing over the smaller shows.

ARM is an example of a small show prevailing over the much better equipped in many ways. ARM was an implementation inspired by existing RISC designs, though the ARM was successful, the others were not. The ARM had a few things all to its own (for the most part) that made it ideal for using High Level Languages, and implementing optimizing compilers, like all instructions being conditional, a completely open register set, the lack of specifying in HW which register to use for stack, etc. The ARM was a greate design for the things that the researchers would have ommited as they do not fit the research models.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:32 pm

Heater wrote:
Sat Dec 01, 2018 10:22 pm
DavidS,

I hate the idea that everything is now getting concentrated to Youtube. That is to say Google. That cannot be good in the long run. That is not any kind of "cloud", that is a centralized server owned by a monopoly. Sorry, there is not much I can do about it except shout to the clouds like the old man that I am.

I have no idea what you mean about the phone. I have modern day "smart" phones. I never use them to watch video. I prefer the comfort of my ancient PC's or laptops.
I have two choices, either reboot my RPi 3B into Linux (and I am in the middle of a compile right now), or I can watch it on my phone. I would prefer to watch it on the RPi, though last time I did this compile clean (had to clean this time) it took 18 hours (ok that was on a RPi B+, so may be faster now).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:33 pm

jahboater,
Just over 20% of the instructions are conditional jumps...
Certainly all normal code will have a lot of conditional jumps.

The question then is: What is the most efficient way to do that?

The RISC V claim is that it can be done without those flags from ALU operations.

Believe it or not? The proof is in the pudding I guess.
Memory in C++ is a leaky abstraction .

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:39 pm

DavidS,
Flags are most definitely a need, otherwise you need a more complex HW implementation to deal with things like conditional execution...
Well. The RISC V claim is that conditional execution is not needed for efficient computation. As noted above only 20% of instructions are conditional jumps. Ergo, most instructions do not need to be conditionally executed, i.e. don't waste hardware on supporting that.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 4769
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:47 pm

Sorry Heater. I do not understand how flags can be avoided.

I can see how ARMv8 avoids the sign flag and the zero flag (in certain cases), but not how the carry flag and overflow flag can be avoided.

I just watched the entire video (very interesting) (ON MY PC!!) but saw nothing at all about the flags.

Please could you explain what the RISC V code looks like for these four common cases?

For example, how exactly would I test for overflow.
For Intel it is "add; jo", for ARM it is "adds; bvs"
What is it for RISC V ?

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 10:54 pm

Ok compile finnished, going to reboot.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 11:09 pm

DavidS,
Put another way, just because great minds think something may work better, does not mean it will.
Very true.

In the RISC V case the ideas of the "great minds" have also been tested over the decades, real chips have been rolled out, lesser minds have measured the outcome.

Looks good so far.
Does anyone remember the MOS6502 8-Bit CPU? Ok do you also remember the i8086, and the M68000?
Yep.
Well when the M68000 came out it was slower than an equally clocked MOS6502.
That may or may not have been so. However we are now mixing up instruction sets with implementations.

I can't help thinking that if the 68000 was such a loser vs 6502 it would never have been adopted in the Sinclair QL, Amiga, Atari ST, Sun work stations etc, etc.
Does anyone remember the many different 16 core 16-bit CISC CPU's that came out in the early 1980's
No. I do not believe there were any. Do you have links to such history?
ARM is an example of a small show prevailing over the much better equipped in many ways. ARM was an implementation inspired by existing RISC designs, though the ARM was successful, the others were not.
Yep. And where did those RISC ideas come from? From Dave Patterson and co. Now bringing you RISC V.
The ARM was a greate design for the things that the researchers would have ommited as they do not fit the research models.
I don't think so. The whole idea came from the researchers at Berkeley.
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 11:21 pm

Berkeley RISC did NOT have all instructions as conditional, or any of the other things that made optimization so easy with the ARM.

Now it is true that the core concept of RISC is part of what made the ARM so great. Though how many Berkeley RISC devices do you see today (not devices inspired by it, the actual Berkeley RISC)?

For a time it looked like MIPS would be the winner, then ARM overtook the RISC world. None of this mattered to me, I am a ARM user for a long time (with a few 680x0 systems on the side, and a couple 6502 based).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 01, 2018 11:34 pm

jahboater,
Sorry Heater. I do not understand how flags can be avoided.
I think the best I can do is refer you to the RISC V instruction set specification:
https://content.riscv.org/wp-content/up ... c-v2.2.pdf

It's short and sweet.
For example, how exactly would I test for overflow.
Well, it might not be so easy.

But I think therein lies a point, most code never checks for overflow. It just overflows and produces the wrong result. See my comments earlier in this thread.

So why bother to go out of your way to support such a thing in the instruction set when nobody uses it?
Memory in C++ is a leaky abstraction .

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sun Dec 02, 2018 12:07 am

DavidS,
Berkeley RISC did NOT have all instructions as conditional, or any of the other things that made optimization so easy with the ARM.
RISC V does not have "all instructions as conditional" either. I guess they have found over the years that it is not necessary to get optimal code. It's not like that isn't an obvious idea that a research group would not investigate in all these years.
Though how many Berkeley RISC devices do you see today (not devices inspired by it, the actual Berkeley RISC)?
Why, none of course.

The original Berkeley RISC was mostly an idea. A research project at a university. Exploring the idea that you could make a processor really simple. No micro-code required. Try to do everything in one clock. Pipeline it all. Create those lesser used CISC instructions from multiple RISC instructions. And so on.

That idea did actually get rolled out as real silicon within the Berkeley group but that is not the point.

The RISC idea, pushed by Patterson and co. at Berkeley, inspired the MIPS processor, the Sun Sparc, the Power PC, the Intel 860, and oh yes the ARM.

Since then there have been follow on research projects at Berkeley. And chips rolled out.

The RISC V is the fifth one. The culmination of everything learned over all the decades of computing history.

And now it's a real specification, cast in stone.

Today it is being adopted by Nvidia for it's graphics cards, Western Digital for it's storage controllers, countless others for all kind of things.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 4769
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sun Dec 02, 2018 12:49 am

Thanks for the link.
Heater wrote:
Sat Dec 01, 2018 11:34 pm
For example, how exactly would I test for overflow.
Well, it might not be so easy.
I looked it up. The compiler has to insert code to work it out afterwards.

Code: Select all

For general signed addition,  three additional instructions after the addition are required,
leveraging the observation that the sum should be less than one of the operands if and only if the
other operand is negative.
add t0, t1, t2
slti t3, t2, 0
slt t4, t0, t1
bne t3, t4, overflow
Add is the easy case, I suppose things like INT_MIN/-1 must be checked a priori.

To be fair, ARM is hopeless at overflow checking too (it only sets the V flag for 32-bit add and subtract)
I'll look up how to do carry now. You cant say that's never used :)
ARM does properly set the carry flag.

Heater
Posts: 13642
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sun Dec 02, 2018 1:12 am

Nothing special about the carry flag. It's the same number range overflow flag for unsigned integers as the "overflow" flag is for signed integers.

Most code never cares about that so why build it into the ISA specification?

It's not just that these flags might be useful, its that if you have them you then have to have other instructions that test them or use them. For example you might then need an ADD that does not care about carry and an ADC that does.

Nope, too complex, skip it. On the rare occasion people want a carry it can be synthesized with other instructions.

Those flags are only cherished by old skool assembler programmers.
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sun Dec 02, 2018 1:48 am

Thanks for that video Heater. He does a good job at making RISC V not look appealing (He uses the only kind of CISC like ARM instructions [LDM/STM] as a poor excuse to call the ARM ISA CISC), he is making it look like those in the RISC V research are ignorant to the nature of the other ISA's completely. He actually talked about the ARM as if it is supposed to have micro-ops, which is wrong, completely wrong. He also used a compilers output for comparisons with -O3, and we all know that the optimizations are going to very wildly depending on the target, as each target will do better with a bit different optimization.

I have seen much better presentations on the RISC V, some that actually would make someone look at it, that was a case of making one want nothing to do with it. I am still kind of looking at RISC V, as I have seen much better presentations of the architecture. May I recommend finding a better representation of RISC V to point people at?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Return to “Off topic discussion”