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

Re: Divide By Depth??

Tue Nov 13, 2018 12:20 am

Gavinmc42 wrote:
Tue Nov 13, 2018 12:14 am
Pair amber with some very simple periphials, and one of the Open source GPU's, implement the ASIC, slap a good PMMU in the system, and put it on a board with 3GB of DDR RAM and that would be the perfect next gen Raspberry Pi, especially if the ASIC had 8 of these Amber Cores (and the associated PMMU's). Though that is just dreaming.
Open source GPU's? I must have missed them, which ones are you referring too?
I have been thinking about learning RISC-V but I would like graphics.
There are a few that have been done, they are not what I would call usable YET. Though if you browse OpenCores you will see some examples, some beter than others, some more complete than others.

It should not be long before we see a usable open source GPU. There are already working examples, and more to come.
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: Divide By Depth??

Tue Nov 13, 2018 12:30 am

Gavinmc42 wrote:
Tue Nov 13, 2018 12:14 am
Pair amber with some very simple periphials, and one of the Open source GPU's, implement the ASIC, slap a good PMMU in the system, and put it on a board with 3GB of DDR RAM and that would be the perfect next gen Raspberry Pi, especially if the ASIC had 8 of these Amber Cores (and the associated PMMU's). Though that is just dreaming.
Open source GPU's? I must have missed them, which ones are you referring too?
I have been thinking about learning RISC-V but I would like graphics.
One example is OpenGFX430, this is a 2D GPU, though it works and is a big step in the correct direction.

Theia is another example, though I do not think it is likely to be very usable for the purpose of a SoC or computer.

The best one that I know of is ORSoC Graphic Accelerator, that has some real potential as a GPU. And if I were to suggest one from what is available today this is the one I would sugest.

I hope that helps.
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
Paeryn
Posts: 2680
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Divide By Depth??

Tue Nov 13, 2018 12:51 am

ejolson wrote:
Mon Nov 12, 2018 10:20 pm
Paeryn wrote:
Mon Nov 12, 2018 5:38 pm
jahboater wrote:
Mon Nov 12, 2018 4:02 pm
I see ARMv8 does half precision (16-bit) floating point too, I didn't know that.
It only supports half precision as a data type when converting, it can't do any arithmetic on half precision values.
I think if you are running in 64-bit ARMv8 mode the NEON FPU supports vector operations on eight half-precision floats at a time. It is possible that access to half-precision floating point is a more compelling reason for a 64-bit operating system than any of the other points mentioned so far.

I think 64-bit mode might be easier than SMP multiprocessing. Are there any development efforts towards making RISCOS run in 64-bit mode?
Ahh, I see... Half-precision fp arithmetic was introduced in ARMv8.2 and even then it's optional, so you'd need at least an A55 or A75. I like the idea of SVE allowing for a core to potentially support up to 2048 bit vectors.

<Addendum> If 8.2-FP16 is implemented then half-floats are valid for both scalar and vector arithmetic as well as in both AArch32 and AArch64 states.
She who travels light — forgot something.

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

Re: Divide By Depth??

Tue Nov 13, 2018 4:03 am

Heater wrote:
Mon Nov 12, 2018 11:37 pm
I don't understand. Could you explain what you mean by "restrictive" or "non-restrictive" instruction set. What restrictions are we talking about?
I believe this means "optional" features - similar to RISCV - in case a manufacturer wants to reduce power or cost.

Since 2011 when ARMv8 was introduced, ARM have seen sense and drawn a line in the sand.
All ARMv8 CPU's are guaranteed to have full IEEE floating point, SIMD and all the other stuff like integer division you expect on a CPU.
So its now easy to program.

They have recently started adding more and more options again (see the FP16 comments above), but these are more esoteric things not many users will need. The basics must be present.

ejolson
Posts: 3588
Joined: Tue Mar 18, 2014 11:47 am

Re: Divide By Depth??

Tue Nov 13, 2018 4:39 am

Paeryn wrote:
Tue Nov 13, 2018 12:51 am
ejolson wrote:
Mon Nov 12, 2018 10:20 pm
Paeryn wrote:
Mon Nov 12, 2018 5:38 pm

It only supports half precision as a data type when converting, it can't do any arithmetic on half precision values.
I think if you are running in 64-bit ARMv8 mode the NEON FPU supports vector operations on eight half-precision floats at a time. It is possible that access to half-precision floating point is a more compelling reason for a 64-bit operating system than any of the other points mentioned so far.

I think 64-bit mode might be easier than SMP multiprocessing. Are there any development efforts towards making RISCOS run in 64-bit mode?
Ahh, I see... Half-precision fp arithmetic was introduced in ARMv8.2 and even then it's optional, so you'd need at least an A55 or A75. I like the idea of SVE allowing for a core to potentially support up to 2048 bit vectors.

<Addendum> If 8.2-FP16 is implemented then half-floats are valid for both scalar and vector arithmetic as well as in both AArch32 and AArch64 states.
I think you are right about half-precision floats also being available in 32-bit mode. I missed that. Thanks for the correction.

If a program can run on a larger number of computers, then the prerequisites for running the program are less restrictive. If the program runs on fewer computers use of the code is more restrictive.

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

Re: Divide By Depth??

Tue Nov 13, 2018 5:25 am

I do not see how adding a bunch of things (like SIMD) makes it easier to program?

While there are things for which I will use VFP (though not NEON, as I still use RPi B+ boards as primary computers, still to many programs that break on the RPi 3B), it is definitely more work than doing the same thing the traditional way. As such the payoff has to be worth the extra effort to use the extension.

So it seems a bit rediculous to me.

Ok I see the point of including floating point as standard, though SIMD should be optional.

Divide is one on which I am still split in opinion, it is nice to have, though I am not sure of how much of a benifit it really is. I have not yet looked up the instruction execution time for divide, or the instruction latancy (as we are dealing with a pipelined CPU), though I do know that the majority of divides in software (with a macro) will execute in under 20 instruction cycles, yes it is possible to take longer though that is rare.

There is the side of the issue that divide is an instruction that is very rarely executed, and this is why my opinion on divide is divided. Most algorithms that do use divide will only use it outside of any loops (the exception being things like depth correction).
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: 4695
Joined: Wed Feb 04, 2015 6:38 pm

Re: Divide By Depth??

Tue Nov 13, 2018 7:40 am

DavidS wrote:
Tue Nov 13, 2018 5:25 am
Ok I see the point of including floating point as standard, though SIMD should be optional.
It seems that on modern computers they just use the first lane of the SIMD registers for the scalar floating-point registers.
The latest Intel CPU's, have 512-bit registers and floats use the bottom 32 or 64 bits :)
DavidS wrote:
Tue Nov 13, 2018 5:25 am
Divide is one on which I am still split in opinion, it is nice to have, though I am not sure of how much of a benifit it really is. I have not yet looked up the instruction execution time for divide, or the instruction latency (as we are dealing with a pipelined CPU), though I do know that the majority of divides in software (with a macro) will execute in under 20 instruction cycles, yes it is possible to take longer though that is rare.
For me its just much more convenient when writing assembler to have SDIV and UDIV instructions instead of having to find a decent function!
Even though the ARM ones are pretty limited. The Intel instruction takes two argument registers and returns the quotient in one and the remainder in the other. The ARM ones on the other hand are half width and don't produce the remainder. You have to follow them with a multiply-sub insn (MLS or MSUB) to get the remainder. But they are fast.

The timings for divide (Cortex-A7) are:-

Code: Select all

                      clocks  latency
SDIV Rd, Rn, Rm 	4-20 	6-22
UDIV Rd, Rn, Rm 	3-19 	5-21
If you can better that in software I am very impressed!

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

Re: Divide By Depth??

Tue Nov 13, 2018 8:58 am

jahboater wrote:
Tue Nov 13, 2018 7:40 am
DavidS wrote:
Tue Nov 13, 2018 5:25 am
Ok I see the point of including floating point as standard, though SIMD should be optional.
It seems that on modern computers they just use the first lane of the SIMD registers for the scalar floating-point registers.
The latest Intel CPU's, have 512-bit registers and floats use the bottom 32 or 64 bits :)
No one ever accused Intel of having decent design sence. Remember that before they put a reduced pipeline core in the Pentium they were one of the slowest CPU's per clock, and even after that they mostly brute force performance.
For me its just much more convenient when writing assembler to have SDIV and UDIV instructions instead of having to find a decent function!
Even though the ARM ones are pretty limited. The Intel instruction takes two argument registers and returns the quotient in one and the remainder in the other. The ARM ones on the other hand are half width and don't produce the remainder. You have to follow them with a multiply-sub insn (MLS or MSUB) to get the remainder. But they are fast.

The timings for divide (Cortex-A7) are:-

Code: Select all

                      clocks  latency
SDIV Rd, Rn, Rm 	4-20 	6-22
UDIV Rd, Rn, Rm 	3-19 	5-21
If you can better that in software I am very impressed!
That is impressively fast for a divide on a simple piplined CPU. And a much more reasonable implementation than Intel 80x86 or Motorola 680x0 did.

I do not think anyone could keep up in software, we are about two times slower in software.

Now if only they would have added the divide a long time ago, to many ARMv4, ARMv5, ARMv6 CPU's still in use. And I just did a bit more research and there are new ARMv3 and ARMv4 CPU's coming out, so far only for FPGA, though it will likely not be long before we see a new generation of ARMv4 SoC's, that may be able to keep up with the ARMv8 in 32 bit mode (some of the superscalar stuff people are doing in reimplementing the older ARM ISA's is amazing, runs circles around anything else I have seen on a instructions average per core per clock real world software).


Well it is good to know about, and the macros that most of us write for division look a lot like the UDIV/SDIV instructions on ARMv7/ARMv8 CPU's in there usage (not implementation obviously).
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: 13383
Joined: Tue Jul 17, 2012 3:02 pm

Re: Divide By Depth??

Tue Nov 13, 2018 11:12 am

DavidS,
...there are new ARMv3 and ARMv4 CPU's coming out, so far only for FPGA, though it will likely not be long before we see a new generation of ARMv4 SoC's, that may be able to keep up with the ARMv8 in 32 bit mode (some of the superscalar stuff people are doing in reimplementing the older ARM ISA's is amazing...
That's interesting. Who is making these souped up older ARM designs? I can't find any references.
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: Divide By Depth??

Tue Nov 13, 2018 8:48 pm

Heater wrote:
Tue Nov 13, 2018 11:12 am
DavidS,
...there are new ARMv3 and ARMv4 CPU's coming out, so far only for FPGA, though it will likely not be long before we see a new generation of ARMv4 SoC's, that may be able to keep up with the ARMv8 in 32 bit mode (some of the superscalar stuff people are doing in reimplementing the older ARM ISA's is amazing...
That's interesting. Who is making these souped up older ARM designs? I can't find any references.
I would not call them souped up, at leas not at the speeds they run in FPGA. Now maybe souped up once someone actually makes an ASIC of one or more of them.

Search open cores for ARMv4, that should turn up two examples (though as far as I know still only for personal use, I think ARM patents prevent commercial use at this time).
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: 13383
Joined: Tue Jul 17, 2012 3:02 pm

Re: Divide By Depth??

Wed Nov 14, 2018 2:02 am

DavidS,

I'm aware that a processor implemented in FPGA is not going to attain the speed of silicon built to do the job. When I said "souped up" I was referring to your description of these new ARM cores as "amazing" and "runs circles" around. Perhaps I should have put quotes around it.

I know that people have created ARM cores for FPGA. For example the AMBA which is an ARM 2 or something. Old enough that ARM makes no IP claims on it. These are hobby level projects.

My point is that these hobby cores are not going anywhere. Their existence does not indicate that there will ever be "a new generation of ARMv4 SoC's, that may be able to keep up with the ARMv8 in 32 bit mode ...".

Nobody can do that due to ARMs IP stranglehold.

Besides there is no point. We now have the open source RISC V core which is gaining a huge following very rapidly. ARMs days are numbered.
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: Divide By Depth??

Wed Nov 14, 2018 4:01 pm

Heater wrote:
Wed Nov 14, 2018 2:02 am
DavidS,

I'm aware that a processor implemented in FPGA is not going to attain the speed of silicon built to do the job. When I said "souped up" I was referring to your description of these new ARM cores as "amazing" and "runs circles" around. Perhaps I should have put quotes around it.

I know that people have created ARM cores for FPGA. For example the AMBA which is an ARM 2 or something. Old enough that ARM makes no IP claims on it. These are hobby level projects.

My point is that these hobby cores are not going anywhere. Their existence does not indicate that there will ever be "a new generation of ARMv4 SoC's, that may be able to keep up with the ARMv8 in 32 bit mode ...".

Nobody can do that due to ARMs IP stranglehold.

Besides there is no point. We now have the open source RISC V core which is gaining a huge following very rapidly. ARMs days are numbered.
I beg to differ on the no point issue.

There is a lot of ARM code out there, that is still very usefull. RISC V for all its clout will not run ARM code.

And I am aware of at least one SoC that does implement the Amber Core already, for the purpose of running Acorn Archimedes software. At present it is intended for implementation in FPGA, though it does exist.

I do not think that ARM would stand in the way of people implementing modern micro architecures that use the ARMv2 ISA, I think that even ARMv3 is old enough that ARM would not care. I could be wrong.
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

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23709
Joined: Sat Jul 30, 2011 7:41 pm

Re: Divide By Depth??

Wed Nov 14, 2018 4:11 pm

Heater wrote:
Wed Nov 14, 2018 2:02 am
Besides there is no point. We now have the open source RISC V core which is gaining a huge following very rapidly. ARMs days are numbered.
Numbered, in decades.

Going to be that long before RISC-V catches up, if at all.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

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

Re: Divide By Depth??

Wed Nov 14, 2018 6:36 pm

DavidS,
I beg to differ on the no point issue....There is a lot of ARM code out there, that is still very useful.
As much as I lusted after a Archie when they were current I never got to own one and as such I know very little of the RISC OS world.

So my question is: What ARM RISC OS code is unique? I imagine there are equivalents of everything ever available on RISC OS now available as Open Source for Linux and other OS.

Unless you can point to one example of a "must have" RISC OS program that has no alternative elsewhere I'm sticking to my "no point" stance.
I am aware of at least one SoC that does implement the Amber Core already,
Do you mean this one: https://opencores.org/projects/amber ?

Seems like a neat and complete project. It's no going to fly outside hobbyist FPGAs.
Memory in C++ is a leaky abstraction .

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

Re: Divide By Depth??

Wed Nov 14, 2018 6:47 pm

jamesh,
Numbered, in decades...Going to be that long before RISC-V catches up, if at all.
I am under no illusion that Intel and ARM machines won't be dominant for a long time in server/desktop and mobile spaces respectively. There is too much other infrastructure around them, hardware and software, to make a switch a speedy matter.

However it already amazes me how much progress RISC V has made in a short time:

a) Western Digital adopting RISC V for it's storage controllers.

b) Nvidia adopting RISC V for use in it's GPUs.

c) People like these guys making RISC V IoT devices with DSP/FFT/Neral net accelerators https://item.taobao.com/item.htm?id=578484113485

d) There are many of the biggest industry names supporting the RISC V Foundation. Including Facebook of all people.

All of this points to a growing market of new and iteresting devices/applications that ARM will be shut out from because of the arrival of the license free and open RISC V.

So as to ride the wave here I'm busy creating my own RISC V core and SoC for FPGA in Verilog. So far I have got a UART working.... :)
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: Divide By Depth??

Wed Nov 14, 2018 10:19 pm

Heater wrote:
Wed Nov 14, 2018 6:36 pm
DavidS,
I beg to differ on the no point issue....There is a lot of ARM code out there, that is still very useful.
As much as I lusted after a Archie when they were current I never got to own one and as such I know very little of the RISC OS world.

So my question is: What ARM RISC OS code is unique? I imagine there are equivalents of everything ever available on RISC OS now available as Open Source for Linux and other OS.

Unless you can point to one example of a "must have" RISC OS program that has no alternative elsewhere I'm sticking to my "no point" stance.
Not the point. There are many IDE's today, I would not use any of them, as the RISC OS way is better (the difference is not always the program, sometimes it is the way of doing things).

For example using !Zap and having the icon bar front ends of the compilers loaded, it is a lot more intuitive to just drag the source (in some cases directly from the editor window) to the compiler (especially for assembly). !Zap is a programmers highlighting text editor, with extras such as compile button, support for throwback (to report errors from the compilers), etc.

There are many examples of it being the way things are done. Of course there are a few unique applications on RISC OS as well, some of which are unique to RISC OS, though the same goes for any OS.
I am aware of at least one SoC that does implement the Amber Core already,
Do you mean this one: https://opencores.org/projects/amber ?

Seems like a neat and complete project. It's no going to fly outside hobbyist FPGAs.
That is the ARM part. The one I am thinking about implements a complete Acorn Archimedes.

All you said is none of them would likely become a successful SoC, even if it is just in FPGA by hobbyists it is still a SoC, and if used by multiple people outside the original project it is successful
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: 13383
Joined: Tue Jul 17, 2012 3:02 pm

Re: Divide By Depth??

Wed Nov 14, 2018 11:28 pm

I'm all for "computer Archaeology". It's good that our computing history is remembered and examples of it are maintained and still working. Both hardware and software. I did build a Z80 emulator for the Propeller and run CP/M on it. Recently I have been pondering getting the Motorola 68000 chips I have running. I just salvaged a couple of Intel 8086 boards from a 1980 vintage embedded system that I have to get running.

However, I'm not about to start investing lots of time creating new software for such things. There is no point. There is a vanishingly small chance that anything I create is interesting or useful to anyone, although amazingly that does happen occasionally which cheers me up no end. If I were to target some relic the potential audience would be zero.

When it comes to RISC OS as an example, it is of no use. None of the software that I use will run on it. Be they compilers, language run times, web browsers/servers, circuit simulators, FPGA synthesis tools, etc, etc.
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: Divide By Depth??

Thu Nov 15, 2018 2:10 am

Heater wrote:
Wed Nov 14, 2018 11:28 pm
I'm all for "computer Archaeology". It's good that our computing history is remembered and examples of it are maintained and still working. Both hardware and software. I did build a Z80 emulator for the Propeller and run CP/M on it. Recently I have been pondering getting the Motorola 68000 chips I have running. I just salvaged a couple of Intel 8086 boards from a 1980 vintage embedded system that I have to get running.

However, I'm not about to start investing lots of time creating new software for such things. There is no point. There is a vanishingly small chance that anything I create is interesting or useful to anyone, although amazingly that does happen occasionally which cheers me up no end. If I were to target some relic the potential audience would be zero.

When it comes to RISC OS as an example, it is of no use. None of the software that I use will run on it. Be they compilers, language run times, web browsers/servers, circuit simulators, FPGA synthesis tools, etc, etc.
What am I missing? If you consider the ARM in your statement as a vintage system, then that is ok. You do not have to create software for the Raspberry Pi, iPad, iPhone, Android devices, etc, no need stick with your modern CISC 80x86 systems (non-macs and intel/amd based PC's).
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: Divide By Depth??

Thu Nov 15, 2018 2:12 am

Also if Facebook is supporting RISC-V already that automatically counts me out. I am one that boycots Facebook.
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
Gavinmc42
Posts: 3758
Joined: Wed Aug 28, 2013 3:31 am

Re: Divide By Depth??

Thu Nov 15, 2018 6:30 am

One example is OpenGFX430, this is a 2D GPU, though it works and is a big step in the correct direction.

Their is another example, though I do not think it is likely to be very usable for the purpose of a SoC or computer.

The best one that I know of is ORSoC Graphic Accelerator, that has some real potential as a GPU. And if I were to suggest one from what is available today this is the one I would sugest.

I hope that helps.
Thanks, need to spend some time on Opencores

OpenCL etc can run on GPU and new accelerators are coming for ML, CV, AL use.
So can generic machine learning accelerators be used also as GPU's?
The VC4 has 12 QPU (48 ALUs) plus 2 vector ALU's etc.
So simple opencore ALU which can do lots of things and you have 64, 128, 256, 512, 1024 of them?

I guess that parallax (8-16 cores) sort of fits?
Those Nvidia chips.
Adapteva - 1billion cores :shock:

They say 8bits is enough for machine learning, so lots of 8bit ALU's or 32bit RGBA ALU's?
How good does the floating point need to be?
Totally soft core, all fpga based?
Perhaps analog graphite memsistor cpus or nano-ram memory/logic/alus?
Can Nantero make logic gates with their tech?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Divide By Depth??

Thu Nov 15, 2018 6:34 am

DavidS,
What am I missing? If you consider the ARM in your statement as a vintage system, then that is ok. You do not have to create software for the Raspberry Pi, iPad, iPhone, Android devices, etc, no need stick with your modern CISC 80x86 systems (non-macs and intel/amd based PC's)
What you are missing is that I consider ARM as it existed in the Archie to be obsolete. Clearly the ARM as we know it from the Pi, all our mobile phones and tabs and billions of embedded devices is not a "vintage system".

ARM, like x86 has evolved over the decades. The x86 we use today is a totally different animal to the x86 that was in the original IBM PC. Especially so with the AMD 64 bit versions that we use today. Similarly current ARMs are far advanced from the ARM that was in the Archie.

My claim is that going out of ones way to ensure that code one writes today runs on the original ARM, the "non-restrictive" instruction set as you call it, is about as pointless as ensuring ones software still runs on the original IBM PC. Except in as much as it may be an interesting exercise in "computer archaeology" to create code for RISC OS. Similar to my fascination with getting my Motorola 68000 chips running one day.

Besides that, I don't write code for the Raspberry Pi, or iPad, iPhone, Android devices or indeed anything else. I strive to ensure that any code I write is as cross-platform as possible.
Also if Facebook is supporting RISC-V already that automatically counts me out. I am one that boycots Facebook.
I'm totally with you on the Facebook boycotting. Possible one of the most evil companies that has ever existed.

I do wonder what their motivation is for supporting the RISC V.

Still, that is to reason to boycott RISC V. I could say I'm not going to use the Pi because ARM belongs to Softbank.
Memory in C++ is a leaky abstraction .

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23709
Joined: Sat Jul 30, 2011 7:41 pm

Re: Divide By Depth??

Thu Nov 15, 2018 11:00 am

Heater wrote:
Thu Nov 15, 2018 6:34 am
I'm totally with you on the Facebook boycotting. Possible one of the most evil companies that has ever existed.
Most Big Oil
Most Big Pharma (and small pharma, e.g. Turing Pharacuticals)
All of the tobacco industry
Monsanto
Apple
Nestle
etc etc etc

Facebook probably doesn't even make the top 50.

Chose your battles, but make sure you fight the right people.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

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

Re: Divide By Depth??

Thu Nov 15, 2018 3:18 pm

@Heater:
Thank you for clarifying your stance on ARM. Though that is not what I am saying.

There is a lot of ARM code in use on the modern ARM CPU's that originated with the older ARM CPU's. There is also a whole lot of modern ARM code currently in use (and more being written every single day), that will not run on the RISC V. The ARM has stayed with pretty much the same core ISA making it easy to keep updating old code, it also makes it reasonable to write code for the newer ARM CPU's from scratch.

Remember ARM assembly has been used on many different systems, very heavily. Especially the game systems that have used ARM CPU's (like the GBA) have a lot of ARM code floating around, a good chunk of which ends up getting used in newer projects. There is even some Android software written in ARM Assembly, some Linux software, etc, etc.

So RISC V is behind the curve in that regards, it would take 35 years for RISC V to catch up if RISC V becomes popular enough to ever catch up.

I am all for RISC V and other open source RISC CPU projects (there seem to be more working examples every couple months). Even the MIPS 2K examples are worth looking at, if nothing else as a base to do something more with. Or the hardware implementations of DLX, that is truely open source (and holds the possibility of porting a lot of the ARM code to with automatic translation, as it is very similar to the ARM).
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: Divide By Depth??

Thu Nov 15, 2018 5:48 pm

Regarding the origingal thread topic:
As I can not find any recent devices that run RISC OS and do not have the divide instructions, I am not going to worry about using them.

I have also decided to stop worrying about using assembly. Instead I am going to get it working completely in BBC BASIC V, then rewrite it in C (using gcc, outputing an AIF that uses CLib [not UnixLib]).

Just anyone does not know the command line to compile a C source to an AIF with gcc, using CLib takes the form:

Code: Select all

gcc -mlibscl -Wall -std=c99 -o OutputName SourceCFileName.c
This works well, and what I have been using as I can not afford to update my copy of the DDE.

I do thank everyone for the conversation.
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: 13383
Joined: Tue Jul 17, 2012 3:02 pm

Re: Divide By Depth??

Thu Nov 15, 2018 8:09 pm

I could not find any way to get gcc to generate AIF files. If you know the AIF format then perhaps it's possible to use GCC's objdump utiity to dump the executable format in various textual formats and write a converter from one of those to AIF.

What is that gcc option you have there "-mlibscl"? I cannot find any reference to that option in any GCC documentation.

I was curious as to what DDE is. I can't find any reference to that on the web either.

Aside:
So RISC V is behind the curve in that regards, it would take 35 years for RISC V to catch up if RISC V becomes popular enough to ever catch up.
More like 35 months and it's mostly done already. GCC and Clang now target RISC V. RISC V is officially supported by the Linux kernel. Almost all of Debian and RedHat and other Linux distributions have RISC V builds, that's tens of thousands of packages that we know and love.

There are some important things still missing. Like a JVM and modern Javascript engines for browsers.

There is a paradox here: Whilst the instruction set is the most important interface in all of computer science it is not expected that people start writing lots of code in RISC V assembler.
Memory in C++ is a leaky abstraction .

Return to “Graphics programming”