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

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 3:37 am

Wow 27 pages already, that is unexpected.
plugwash wrote:
Thu Dec 13, 2018 7:17 pm
I would advise not relying on oabi compatibility support going forward. Apparently it's still enabled in raspberry pi foundation kernels but other kernels may have it turned off (it comes at a performance penalty) and arm64 kernels don't support it at all.
I thought that Linus was apposed to breaking compatibility of the user space from changes to the kernel? That would be a break in compatibility for ARM based systems (Yea I know that the old documentation from the mid to late 1990's said that the kernel API is subject to change without notice).

I will say that the quickest way to get me to never again look at Linux would be to break this compatibility. As it stands it is still possible to build the kernel without EABI having only OABI, and I would be apposed to any distro that goes the other way around if it targets 32-bit ARM (I understand the reason for THUMB and AARCH64 targets, they have no way to encode the call number).

As to it adding to system call overhead, yes it does by very little (have not looked at the Linux source for this yet), it can be as little as 6 instructions to fetch and decode and branch, with only two potential pipeline stalls (so about 8-9 clocks at in the worse case to decode, assuming cached), and it takes how much to decode the new way (could be as little as 4 instructions and one pipeline stall, making as much as 6 clocks added). So if done the most effecient way (do not know for sure how Linux does it) the EABI can potentially save as much as 3 clock cycles, less if a little extra care is taken.
That is not significant enough for the low frequency with which system calls should be made, and does not account for the overhead on the caller of loading one more register (so only 1 clock potential savings including the originating side of the call).

Using OABI style calling:

Code: Select all

MaxCall DCW &900179
SwiEntry
   STMFD  R13!,{R4,R5}
   LDR    R5,MaxCall                  ;Get upper bounds of call range.
   LDR    R4,[R14, #-4]               ;Get call number.
   BIC    R4,#&FF000000
   SUBS   R4, R5, R4                  ;Calculate index into call table.
   LDRGE  R15, [R15, R4, LSL #2]      ;This loads from the table.
   B      BadCall                     ;If we get here bad call.
SwTable
   ;word entries pointing to handlers, in decending order with 0x179
   ;  first and 0 last.
And using R7:

Code: Select all

MaxCall DCW &179                      ;The last system call in current Linux.
SwiEntry
   STMFD  R13!,{R5}
   LDR    R5,MaxCall                  ;Get upper bounds of call range.
   SUBS   R7, R5, R7
   LDRGE  R15, [R15, R7, LSL #2]      ;This loads from the table.
   B      BadCall                     ;If we get here bad call.
SwTable
   ;word entries pointing to handlers, in decending order with MaxCall
   ;  first and 0 last.
So how again is it that it is saving a lot of overhead? It seems to me that it is likely to add at least two instructions on the caller to preserve and load R7, as well as the same memory overhead. So in reality if done reasonably this is an even either way kind of situation.

I will have to look at the Linux source for handling SWI's on ARM both EABI and OABI to see how he does it, see if maybe there is more savings than there should be (with a kernel compiled for pure OABI vs having both vs EABI only).
Last edited by DavidS on Fri Dec 14, 2018 4:12 am, edited 1 time in total.
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?

Fri Dec 14, 2018 3:54 am

Just looked at the Linux kernel source for the SWI handler (as commented in the Linux source SWI), and it is a bit convoluted to an unneeded point. The way they do it, yes it makes a bigger difference. Can definitely tell that those that contributed that code are NOT ARM Assembly coders at all (though there solution does work, and is good enough for our needs).

And a note on my code above:
I would add a preservation of R14 and loading R14 with the address of a standard return routine (that would be the same in both cases). Thus the handlers only have to do a normal style return to the handler, and everything ends up correct.
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?

Fri Dec 14, 2018 5:12 am

This question of OABI vs EABI got me thinking about what it would take to support both on the same system easily, assuming ARM 32-bit ISA, and how much overhead could be saved versus what the current Linux implementation provides.

So I decided to take some time looking at different ways to implement both types of call in a way that could work, and this is the most effecient version I could come up with (ok the two could be reversed in the code if the R7 call number is prefered, with the same results). Admitedly I did not spend a lot of time on it.

Code: Select all

SwRetCode
   LDMFD  R13!, {R8-R9, R15}


SwiEntry
   STMFD  R13!, {R8-R9, R14}          ;Preserve R4 and R5, we use them.
   LDR    R9, MaxCall                 ;Get upper bounds of call range.
   LDR    R8, [R14, #-4]              ;Get call number.
   BIC    R8, #&FF000000
   SUBS   R8, R9, R8                  ;Calculate index into call table.
   ADR    R14, SwRetCode

   ADD    R8, R8, #4                  ;Skipping over 4 extra words on load of R15.
   LDRGE  R15, [R15, R8, LSL #2]      ;This loads from the table.

   ;If not in range from SWI instruction, lets check for R7 based Call.
   SUB    R9, R9, #&900000            ;Upper bounds for R7 number.
   SUBS   R7, R9, R7                  ;Again calc table offset.
   LDRGE  R15, [R15, R7, LSL #2]      ;Jump by loading to target.
   B      BadCall                     ;If we get here it is a bad call.
MaxCall DCW &900179
SwTable
   ;word entries pointing to handlers, in decending order with 0x179
   ;  first and 0 last.
Note that the line that reads ADD R4, R4, #4 may seem redundant with the preceding SUBS instruction, though it is not as this needs to be done without seting the flags, and otherwise would require an extra instruction to check bounds.

12 instructions total, I think that the Linux kernel version is about 4 times that when compiled to support both.

There is the cache issue on the data reads, though that is not so much an issue when you realize that SWI instructions have a tendancy to land within 8 bytes of some data that is going to need to be cached anyway, so no real loss there.

The unseen part here is still the overhead difference in the code that is making the call, as there is at least one extra load, and potentially an extra store using the call in R7 method.

I guess this is a little off topic, though still worth while.
Last edited by DavidS on Fri Dec 14, 2018 5:17 am, edited 2 times in total.
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: 15807
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 5:13 am

DavidS,
I thought that Linus was apposed to breaking compatibility of the user space from changes to the kernel?
I see no sign that Linux is about to break anything.

OABI support is an option that can be enabled or disabled when you build a kernel. See the source in arch/arm/Kconfig:

Code: Select all

config OABI_COMPAT
	bool "Allow old ABI binaries to run with this kernel (EXPERIMENTAL)"
	depends on AEABI && !THUMB2_KERNEL
	help
	  This option preserves the old syscall interface along with the
	  new (ARM EABI) one. It also provides a compatibility layer to
	  intercept syscalls that have structure arguments which layout
	  in memory differs between the legacy ABI and the new ARM EABI
	  (only for non "thumb" binaries). This option adds a tiny
	  overhead to all syscalls and produces a slightly larger kernel.

	  The seccomp filter system will not be available when this is
	  selected, since there is no way yet to sensibly distinguish
	  between calling conventions during filtering.

	  If you know you'll be using only pure EABI user space then you
	  can say N here. If this option is not selected and you attempt
	  to execute a legacy ABI binary then the result will be
	  UNPREDICTABLE (in fact it can be predicted that it won't work
	  at all). If in doubt say N.
The statement from plugwash was that "it's still enabled in raspberry pi foundation kernels but other kernels may have it turned off". It is the distributor that decides to support things or not in their kernel builds.
I will say that the quickest way to get me to never again look at Linux would be to break this compatibility.
Why for goodness sake? Nobody else in the world seems to care about it. Just get on and write the code already.
Just looked at the Linux kernel source for the SWI handler (as commented in the Linux source SWI), and it is a bit convoluted to an unneeded point. The way they do it, yes it makes a bigger difference. Can definitely tell that those that contributed that code are NOT ARM Assembly coders at all
I suspect they are perfectly fine ARM assembly programmers.

If not then great, now is your chance for fame and glory. If you know a way to optimize that code then submit a patch to the Linux kernel ARM maintainers. Get your name into the Linux kernel sources.

In the context of the current problem, fibo(4784969), saving a few cycles on system calls is not even going to show up in the noise of any execution time measurement. Not worth thinking about.
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 5:15 am

DavidS wrote:
Fri Dec 14, 2018 3:37 am
Wow 27 pages already, that is unexpected.
plugwash wrote:
Thu Dec 13, 2018 7:17 pm
I would advise not relying on oabi compatibility support going forward. Apparently it's still enabled in raspberry pi foundation kernels but other kernels may have it turned off (it comes at a performance penalty) and arm64 kernels don't support it at all.
I thought that Linus was apposed to breaking compatibility of the user space from changes to the kernel?
Just because Linus is opposed to breaking user land doesn't mean some engineer packaging kernels has the same priorities. There is, in fact, evidence that some developers of open source software are more concerned about influence and impact than compatibility and standards. I wonder if 64-bit kernels still support OABI when running 32-bit code. The suggestion "If in doubt say N" is interesting.

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

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 5:25 am

DavidS,
The unseen part here is still the overhead difference in the code that is making the call, as there is at least one extra load, and potentially an extra store using the call in R7 method.
So what you are saying is that in order for your "improved" scheme to work all existing ARM compilers and assemblers would need changing to do that one extra load and possibly store.

Way to break things!
I guess this is a little off topic, though still worth while.
Yes, way off topic. Not worth while, unless you are going to submit your optimizations to the kernel.
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?

Fri Dec 14, 2018 5:25 am

@Heater:
I am writing the code already. And I would hope that no program makes a system call often enough for that small difference to make a huge difference.

Have spent a good deal of time on it today, taking a little extra care in assuring that it is indeed correct as I go.
ejolson wrote:
Fri Dec 14, 2018 5:15 am
DavidS wrote:
Fri Dec 14, 2018 3:37 am
Wow 27 pages already, that is unexpected.
plugwash wrote:
Thu Dec 13, 2018 7:17 pm
I would advise not relying on oabi compatibility support going forward. Apparently it's still enabled in raspberry pi foundation kernels but other kernels may have it turned off (it comes at a performance penalty) and arm64 kernels don't support it at all.
I thought that Linus was apposed to breaking compatibility of the user space from changes to the kernel?
Just because Linus is opposed to breaking user land doesn't mean some engineer packaging kernels has the same priorities. There is, in fact, evidence that some developers of open source software are more concerned about influence and impact than compatibility and standards. I wonder if 64-bit kernels still support OABI when running 32-bit code. The suggestion "If in doubt say N" is interesting.
I am not surprised that there are open sourcers that have a closed source mind set, that is the nature of the beast.

I will have to look at the compile path for AARCH64, as I do not know the answer to the support for OABI in 32-bit ARM soft on the AARCH64 Linux kernel (it takes multiple mode switches to go between AARCH64 and ARM 32bit, so more overhead anyway).
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?

Fri Dec 14, 2018 5:27 am

Heater wrote:
Fri Dec 14, 2018 5:25 am
DavidS,
The unseen part here is still the overhead difference in the code that is making the call, as there is at least one extra load, and potentially an extra store using the call in R7 method.
So what you are saying is that in order for your "improved" scheme to work all existing ARM compilers and assemblers would need changing to do that one extra load and possibly store.

Way to break things!
NO NO.
What I am saying is that a Linux program already has to do an extra load (even if by a move instruction for an immed) in order to call the kernel by the R7 method, and MAY have to save the state of R7 first. That is not breaking things, that is the way it is in Linux now, and part of why I like the OABI.

Are you sure you are not auto translating what I type three or four times before reading it?
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: 15807
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 5:30 am

ejolson,
There is, in fact, evidence that some developers of open source software are more concerned about influence and impact than compatibility and standards.
Ha! That made me chuckle. Yes, there are jerks everywhere.

Do you have a link to such evidence? It would be nice to know which jerks to avoid.

Conversely:

There is, in fact, evidence that pretty much all developers of closed source software are more concerned about profit, money and customer lock-in, than compatibility and standards (Except their own of course).
Memory in C++ is a leaky abstraction .

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

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 5:44 am

DavidS,
NO NO....Are you sure you are not auto translating what I type three or four times before reading it?
Actually, I often read you posts two or three times trying to fathom is there is any possible logic to it :)

Whilst discussing your proposed changes, you wrote:

"The unseen part here is still the overhead difference in the code that is making the call, as there is at least one extra load, and potentially an extra store using the call in R7 method."

Well, that says to me that the code making the call has a load and/or a store more or less to do. That code is generally generated by compilers and assembler. Ergo they would have to accommodate your change.

Perhaps what you were thinking is not what you actually wrote.
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?

Fri Dec 14, 2018 5:56 am

Heater wrote:
Fri Dec 14, 2018 5:44 am
DavidS,
NO NO....Are you sure you are not auto translating what I type three or four times before reading it?
Actually, I often read you posts two or three times trying to fathom is there is any possible logic to it :)

Whilst discussing your proposed changes, you wrote:

"The unseen part here is still the overhead difference in the code that is making the call, as there is at least one extra load, and potentially an extra store using the call in R7 method."

Well, that says to me that the code making the call has a load and/or a store more or less to do. That code is generally generated by compilers and assembler. Ergo they would have to accommodate your change.
NO
I was sighting the difference between the existing OABI and EABI from the callers perspective. In order to make a EABI call you have to put the call number into R7 (storing R7 if currently in use) and then call the SWI in addition to the normal setup for the call. In order to make a OABI call you only need to do the normal setup and the SWI instruction (as the call number is encoded in the SWI opcode).

So NOT MY change, it is the existing difference between OABI and EABI, and that is clear in context, as I am talking directly about the difference between the two calling methods.
Perhaps what you were thinking is not what you actually wrote.
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: 15807
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 6:16 am

DavidS,
So NOT MY change, it is the existing difference between OABI and EABI, and that is clear in context, as I am talking directly about the difference between the two calling methods.
Not clear at all. The context was a post discussing "different ways to implement both types of call in a way that could work, and this is the most effecient version I could come up with"

Anyway, whatever it was you meant it's probably time to move on. I guess no one here is about to make any changes to that kernel xABI call handler.

Meanwhile...

I was pondering the next easy optimization I could make to the C++ solution.

Perhaps the shift() operations would not actually allocate a new shifted version of the given big integer. Rather they would simply record in the big integer structure that there is a shift. That would take no time at all.

Then, the subsequent addition operator would notice it is dealing with shifted numbers, create a result of the required size and then perform the addition into that, with appropriate adjustments of the array offsets according to the shift(s).

We will see ...
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?

Fri Dec 14, 2018 6:23 am

Now that sounds like a good optimization. That should save quite a bit, sliding offsets for shifts, I like.
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: 15807
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 7:31 am

It sounds tempting. A sort of scaled integer data type.

Before doing anything I thought I'd find out how many allocations are being made in different circumstances as fibo(4784969) runs. Here is what I get:

Code: Select all

allocWithWidth: 1422495913           // Allocations of numbers with a specific width.
                                     // Used to create the results of sum, sub, shift and mul
allocCopy:       570643575           // Allocations when copying numbers. The = operator. 
allocString:             3           // Allocations when creating numbers from strings 
allocEquals:             0           //
allocEqualString:        0           // 

allocHigh:               0           // Allocations made by high()
allocLow:                0           // Allocations made by low()
allocShift:      282257348           // Allocations made by shift()
So, with the scaled number idea allocations made by shift go to zero and that reduces the allocWithWidth to: 1422495913 - 282257348 = 288386227.

A saving of about 20%. Sounds like it's worth doing.

That still leaves 288 million allocations done when producing results of sum, sub and mul and the associate memory copy. In most cases the thing being copied is never used again, so the copy was not actually required.

For example, when calculating:

Code: Select all

    bint s1 = z1 - z2;
There is an intermediate result of the subtraction created, which is then copied to a newly malloced "s1" and never used again. Might as well create that intermediate result in the space occupied by z1. Then just put the pointer to it into the s1 structure.

Except in general that destroys z1 which one may actually want later. Tricky.

Hmmm...but we could implement the C style += and -= operators. Then do:

Code: Select all

    bint s1 = z1 -= z2;
That gives the same result whilst overwriting z1. Saving half our allocations and copies. Just what we want!

I don't know if this makes sense to anyone. I'm just thinking aloud. Programming in C++ makes one crazy that way.
Memory in C++ is a leaky abstraction .

User avatar
Gavinmc42
Posts: 4499
Joined: Wed Aug 28, 2013 3:31 am

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 7:52 am

Yep saving the data in a register to reuse it, copying from one register to another register takes time.
Ping pong between registers?
Can we make that go faster by using more registers?
Most languages return subroutine results in R0?
Legacy of when we only had a few registers?

Been staring at the fibo numbers for so long I started seeing other patterns.
f(n) = 2 * f(n-1) - f(n-3) etc

Since these numbers appear in natural objects understanding them might make procedural game coding more realistic.
Any tricks like the karatsuba method will help PG stuff?

Was researching to make PG clouds in a OpenGL skybox, about a dozen names popped up for methods :o
Particle maths is more complex than I expected, time to simplify formula on paper to lines of code.
Craig Reynolds Boids is next, need that for flocking drone code?

Ah the old days of just blinking a LED, now I want to understand how Tensorflow Lite works.
Wonder if any teachers have contradictory feelings about Eben and his little idea?
Starting the have similar feelings about DavidS and his ideas :lol:
My brain hurts and the weekend has not even started.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 9:03 am

Gavinmc42,
Most languages return subroutine results in R0?
Legacy of when we only had a few registers?
You forgot those pesky interrogatives again.

Well, you could write the result out to memory and have the caller pick it up again. But that's extra code and a slow memory access.

You could use other registers but it's best if both parties agree which ones.

It's not always R0. What about when the subroutine is inlined by the compiler as an optimization, then the call and return are gone and whatever registers are convenient are used.

Hmmm... but what happens when more than one value is returned. Some languages allow:

x, y = someFunc(a, b)

Or what about when a structure containing two or more integers is returned.

Questions, questions...

You weekend is wasted. And it has not even started yet :)
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5639
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 9:29 am

The whole discussion about EABI vs OABI is moot - this is new code, no one in their right mind is going to write new code using an old deprecated ABI that may or may not be supported, especially when its trivial to use the current ABI/R7 instead. That's bad engineering. Built-in obsolescence.

The reason why distro's like Debian can release kernels without OABI is because no one is using it anymore. The current EABI is cast in stone and will be around for ever.

The fibo(4784969) takes 9,757,147,315 instructions for my C version on x64, presumably a lot more on ARM.
Saving a handful of instructions by using an old ABI is pointless.

Its X8 on aarch64 by the way

User avatar
Gavinmc42
Posts: 4499
Joined: Wed Aug 28, 2013 3:31 am

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 9:40 am

What language is going to be best for Quantum computers?
Is there a language that uses other bases, Sumerian base 60 is good for Humans, but AI and future computers will use?.
Trinary- Yes, No, Maybe?
Trinary is pretty good for humans too, laws are black(no) and white (yes) but most of the time we live in grey areas.
https://en.wikipedia.org/wiki/Three-valued_logic
https://en.wikipedia.org/wiki/Setun

Gone off topic again :lol:
Ternary -trit code in many languages
https://rosettacode.org/wiki/Ternary_logic#Pascal

Some interesting stuff here, bedtime reading ;)
https://rosettacode.org/wiki/Rosetta_Code
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
PeterO
Posts: 5823
Joined: Sun Jul 22, 2012 4:14 pm

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 9:43 am

jahboater wrote:
Fri Dec 14, 2018 9:29 am
The whole discussion about operating systems is moot - this is new code, no one in their right mind is going to write new code using an old deprecated operating system that may or may not be supported, especially when its trivial to use the current operating systems instead. That's bad engineering. Built-in obsolescence.
Fixed for you.....
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

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

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 9:44 am

jahboater,
The fibo(4784969) takes 9,757,147,315 instructions for my C version
Nine BILLION instructions.... Holds finger to corner of mouth.

Sounds like a huge lot but.

To get a million digit result we need two multiply half million digit wide numbers. Done the school boy way that's already over 250 billion digit by digit multiplies! Never mind all the additions.

Our quick fibo and karatsuba algorithms are working very well for us.

Still, wouldn't want to waste an instruction on a sys call now would we :)
Memory in C++ is a leaky abstraction .

User avatar
Gavinmc42
Posts: 4499
Joined: Wed Aug 28, 2013 3:31 am

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 9:48 am

I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 10:06 am

PeterO,
The whole discussion about operating systems is moot - this is new code, no one in their right mind is going to write new code using an old deprecated operating system that may or may not be supported, especially when its trivial to use the current operating systems instead. That's bad engineering. Built-in obsolescence.
Actually...This thread was about BASIC. So:

The whole discussion about programming languages is moot - this is new code, no one in their right mind is going to write new code using an old deprecated programming language that may or may not be supported, especially when its trivial to use the current programming languages instead. That's bad engineering. Built-in obsolescence.

Hey, weren't you the guy preparing ALGOL 60 to run on whatever an Elliott 803 has for an operating system? :)
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5639
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 10:10 am

Instruction counts FYI :-

Code: Select all

Intel x64 C/karatsuba  9,757,147,315 
Intel x64 C/library      893,244,323 
32-bit ARM C          21,431,994,711 
Aarch64 C              9,270,364,251        
Last edited by jahboater on Fri Dec 14, 2018 10:13 am, edited 1 time in total.

User avatar
PeterO
Posts: 5823
Joined: Sun Jul 22, 2012 4:14 pm

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 10:13 am

Heater wrote:
Fri Dec 14, 2018 10:06 am
Actually...This thread was about BASIC. So:
But have you ever noticed how DavidS manages to turn every thread into a moan about how no one supports RiscOS ?
Hey, weren't you the guy preparing ALGOL 60 to run on whatever an Elliott 803 has for an operating system? :)
No OS on that machine, and I have special dispensation for writing code in Algol-60 as most of it gets used to demonstrate the real hardware in a museum setting.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

jahboater
Posts: 5639
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Fri Dec 14, 2018 10:37 am

PeterO wrote:
Fri Dec 14, 2018 10:13 am
No OS on that machine, and I have special dispensation for writing code in Algol-60 as most of it gets used to demonstrate the real hardware in a museum setting.
No excuses needed.
The number of great modern languages that Algol 60, directly, or indirectly, inspired is countless.

Return to “Off topic discussion”