BCPL examples

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
User avatar
Lardo Boffin
Posts: 1094
Joined: Thu Aug 06, 2015 6:47 am
Contact:

BCPL examples

Post by Lardo Boffin » Mon May 29, 2017 7:17 am

A while ago I decided to learn some BCPL but couldn't find many generic examples or specific Beeb examples beyond a couple in the Acornsoft book so while figuring it out I made a note of the ones I did and stuck them on GitHub. I say a while ago - it was about a year ago looking at the dates of the files...

Anyway if anyone is interested in learning BCPL they may be of interest:-

https://github.com/LardoBoffin

If you are going to give it a go I strongly recommend running it from a co-processor as otherwise you will constantly run out of RAM.

Lardo
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, Viglen twin 40/80 5.25" discs, acorn cassette, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master

bear
Posts: 29
Joined: Sat Jul 16, 2016 10:04 pm
Location: Seattle, USA
Contact:

Re: BCPL examples

Post by bear » Tue May 30, 2017 6:17 pm

About a year ago I started a project to do a simple benchmark that pretty much any '80s home micro could participate in. This took the form of a BASIC program to calculate prime numbers by trial division. I decided I was interested in comparing the performance of BASIC to APL on my IBM 5100, wrote an APL version of the benchmark, and things went out of control from there.

I mention it because one of the most recent versions I produced was BCPL, for the purposes of benchmarking it on my Master 512.

http://typewritten.org/Articles/Benchma ... /bcpl.html

Sorted results:

http://typewritten.org/Articles/Benchmarks/primes.html

User avatar
Lardo Boffin
Posts: 1094
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: BCPL examples

Post by Lardo Boffin » Tue May 30, 2017 9:10 pm

Interesting tests thanks. So BCPL is approximately 3.5 times faster than BASIC IV. I'm surprised it is faster than Fourth - I thought that was supposed to be a really fast language?
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, Viglen twin 40/80 5.25" discs, acorn cassette, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
BBC Master

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BCPL examples

Post by Coeus » Wed May 31, 2017 12:29 am

Interesting BCPL example. You reminded me that back in the 1980s our local radio station had a competition to write the fastest program to find all the primes up to a given number, which I now forget. The program I came up with was something like this:

Code: Select all

GET "libhdr"

MANIFEST $( N=100
            //N=1000
            //N=10000
            V=541
         $)

LET start() BE
$( LET i, j, primes = ?, ?, ?
   primes := GETVEC (V)
   FOR j = 0 TO V $(
      primes!j := 0
   $)
   FOR i = 2 TO V $(
      IF primes!i = 0
      THEN $( writef("%n*n", i)
              j := i
              $( primes!j := 1
                 j := j+i
              $) REPEATUNTIL (j >= V)
      $)
   $)
$)
except that is a new copy of the source hacked from your trial division version because I have no idea where I put the original. I later discovered that this is a well-known algorithm called the Sieve of Eratosthenes (https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes)

Timnings, on B-Em: Trial Division 11.62s, sieve 4.94s

But for the final surprise, this implementation in BASIC 2:

Code: Select all

   10V%=541
   20DIMP%(V%)
   30FORI%=2TOV%
   40IFP%(I%)=0THENPROCfound
   50NEXTI%
   60END
   70DEFPROCfound
   80PRINTI%
   90FORJ%=I%TOV%STEPI%
  100P%(J%)=1
  110NEXTJ%
  120ENDPROC
runs even faster at 4.1s It seems once the core algorithm is faster the execution time depends significantly on I/O. In the BCPL version if I replace the writef calls with writed so there are no newlines between the number and less scrolling I can get the BCPL version down to 3.8s

SteveF
Posts: 510
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: BCPL examples

Post by SteveF » Thu Jun 01, 2017 7:48 pm

Interesting that it's I/O bound it's an I/O test as well as a computation test...

Putting that to one side, are you comparing like with like here on the calculations? BBC BASIC will be using 32-bit integers, whereas I'd guess (i.e. I could be wrong!) the BBC version of BCPL will be using 16-bit words.

bear
Posts: 29
Joined: Sat Jul 16, 2016 10:04 pm
Location: Seattle, USA
Contact:

Re: BCPL examples

Post by bear » Tue Oct 24, 2017 8:56 pm

SteveF wrote:Interesting that it's I/O bound it's an I/O test as well as a computation test...
Yeah, it's deliberately simplistic in this regard. A fast machine with slow console performance will get a slow result... mainly because the project started as a benchmark for '80s home micros, where a lot of the time the two couldn't really be separated. The limitations of the various built-in BASICs are also why the algorithm isn't particularly sophisticated (one area for obvious improvement is to stop checking factors at the square root of the candidate prime, but a number of BASICs don't have square root functions).
SteveF wrote:Putting that to one side, are you comparing like with like here on the calculations? BBC BASIC will be using 32-bit integers, whereas I'd guess (i.e. I could be wrong!) the BBC version of BCPL will be using 16-bit words.
I'm not, no. Whatever features and limitations of the language... that's all part of the ultimate result. The whys of the various results can get quite interesting. Maybe I'll start a column for people who want to guest-write analyses of the results. (@;

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: BCPL examples

Post by crj » Wed Oct 25, 2017 1:40 am

If comparing BCPL with BASIC, it's worth tying to find primes up to a much larger number than 100.

Although the BCPL runtime is pretty lightweight, setting it up and tearing it down still isn't free. And, depending on precisely how you measure, much of BASIC's setup happens long before you type RUN.

Also, as noted, when the numbers are small, IO dominates. When the numbers are larger, ticking off the multiples takes the bulk of the time.


Incidentally, I believe the Level 2 and Level 3 fileservers are written in BCPL. For all I know they're the only non-toy uses ever made of the Beeb's BCPL compiler. (-8

Equally incidentally, Sieve of Eratosthenes was the first ARM program I ever wrote. Needless to say, it went obscenely quickly by 8-bit standards.

User avatar
danielj
Posts: 6285
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: BCPL examples

Post by danielj » Wed Oct 25, 2017 3:16 am

Domesday was written in BCPL on the beeb.

d.

Coeus
Posts: 827
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: BCPL examples

Post by Coeus » Sat Jan 27, 2018 2:24 am

bear wrote:I'm not, no. Whatever features and limitations of the language... that's all part of the ultimate result. The whys of the various results can get quite interesting. Maybe I'll start a column for people who want to guest-write analyses of the results. (@;
Thinking of features of the language I was looking at the results for more modern hardware in the10,000 prime test and was puzzled to see the GNU Ada compiler beating gcc (the C compiler). It looks like this is an interaction of language features and the test program because Ada gets you to declare the range of an integer and then the compiler can choose the next biggest word length on the underlying machine to get the right results. On modern machines that would presumably use 32 bit integers.

The C source has the type of relevant variables as "unsigned long", which may have been 32bit on older machines but on my PC it is 64bit. I get 0.413s using the source as supplied but if I change that type to just "unsigned" so it becomes 32bit I get 0.185s, more than twice as fast.

Anyway, back to the Acorn 8 bit world and I was looking at Pascal as well as Small-C so here's what I get on my BBC B for the 100 prime version of the trial division algorithm:

Code: Select all

Assembler  3s
BCPL      10.5s
Small-C   12.6s
Pascal    21s
BASIC 2   23s
It is interesting that BCPL is faster than Small-C. The BCPL is compiled to CINTCODE which is code for a virtual machine and requires a small interpreter whereas Small-C is compiling to JSR-threaded code much as Forth would use.

Here are some results for the 1000 primes version:

Code: Select all

Assembler  3m47s  (227s)
BCPL      12m04s  (724s)
BASIC     32m08s (1928s)
At 227s the assembler version is still towards the end of that particular table but it is faster than a number of 16bit/32bit machines where the test is being run in a high-level language.

bear
Posts: 29
Joined: Sat Jul 16, 2016 10:04 pm
Location: Seattle, USA
Contact:

Re: BCPL examples

Post by bear » Fri Feb 02, 2018 9:50 pm

Coeus wrote:Thinking of features of the language I was looking at the results for more modern hardware in the10,000 prime test and was puzzled to see the GNU Ada compiler beating gcc (the C compiler). It looks like this is an interaction of language features and the test program because Ada gets you to declare the range of an integer and then the compiler can choose the next biggest word length on the underlying machine to get the right results. On modern machines that would presumably use 32 bit integers.
I think at that tiny amount of elapsed time, the differences are more likely noise. What happened to be in cache, what interrupts were being serviced, what other processes woke up. That kind of thing.
Coeus wrote:The C source has the type of relevant variables as "unsigned long", which may have been 32bit on older machines but on my PC it is 64bit. I get 0.413s using the source as supplied but if I change that type to just "unsigned" so it becomes 32bit I get 0.185s, more than twice as fast.
That's interesting. I hadn't thought much about that for C, but it's an obvious issue with, for example, SBASIC on CP/M, which wants to use packed BCD unless you explicitly declare variables as INTEGER. That makes an enormous difference in performance!

Post Reply