Recently some links were posted benchmarking the various C compilers available for the 6502, so always liking benchmarks I thought I'd have a look at them and translate some of them to BCPL which is what my 65816 system runs ...

The post concerned was this one: viewtopic.php?f=2&t=8094&p=108834#p108823

I looked at the 2nd link and took a few benchmarks to start with - I'd actually been after a CRC type thing for some time so this was of double interest...

I suspected from the outset that my BCPL system would not be fast compared to compiled C (spoiler; it really isn't as fast) - it does compare well to BASIC though.

One of the main issues is that the BCPL compiler compiles to a bytecode and this in-turn is interpreted by the best part of 16KB of native '816 assembly (hand coded by me). The basic overhead per opcode is 29 cycles (or rarely 37 cycles when the program counter crosses a 64KB boundary). Also it's a 32-bit virtual machine and quite word orientated. It doesn't do individual byte sized operations well and while running the '816 in native 16 bit widths does help it's arguably slower that it ought to be due to the 8-bit wide memory, however ...

This is the page I'm taking my lead from: https://gglabs.us/node/2293

It looks like the C sources were compiled to run on a C64 - which is a 1Mhz 6502. My Ruby816 board is a 16Mhz system, so I simply/naively multiplied all my timings by 16 to scale them to that of a 1Mhz system.

The CRCs - the CRC calculations all involve XORs with bytes, but the running CRC is shifted. Byte manipulation is always going to be slower than C as the C compiler can (should) be able to use direct Acc register manipulation for bytes. The BCPL bytecode/virtual machine maintains registers as 32-bit values in zero (direct) page.

CRC: From the web page above, the timings for crc8, 16 and 32 (sdcc is the best here) are: 1.8, 2.7, 4.5 seconds for an 8KB chunk of ROM.

For BCPL they are a somewhat embarrassingly long times of 67, 70, 75 seconds respectively. (Also a 8KB chunk of ROM). Note the relative similarity in timings due to byte operations being handled as words.

Moving on ..

Factorial: the best C was gcc at 176 seconds. BCPL wins here at 120 seconds. That was pleasantly surprising but BCPL is good at recursion and stack handling. Also good at 32-bit arithmetic.

Sieve: The best C sieve was 12.6 seconds (gcc again) BCPL came in at a much slower 250 seconds. This, like the CRC tests is all due to byte handling. I didn't go down to the bitfield version of the Sieve.

Pi: The Pi calculation came out at 96 seconds - the same as SDCC - this is all 32-bit arithmetic though.

POW: gcc was the best C here at 8.7 seconds, however BCPL comes close it at 9.7 seconds. Time to investigate the gcc floating point libraries I think... The other C compilers are 23/37 seconds (vbcc/sdcc)

I've not looked at the others - mostly as they're byte-bashing, so I know BCPL will fare badly there and one day I'll port over dhrystone to BCPL. It's a bit big for a quick and dirty test right now.

Other things of consideration - once upon a time I did some benchmarking as part of a job and we knew how to take some short cuts - here I've tried to keep the BCPL more or less line for line as the C code but one thing - calculating Pi for example - the code I normally use can calculate 100 digits of Pi in 5.4 seconds, or 86 seconds when *16 - slightly faster than the algorithm used here so there's always room for improvement (aka cheating!)

The one thing BCPL will win is code density, and possibly program loading speed - but that's at the expense of a shared run-time library that is pre-loaded into RAM at boot time.

Will this make me switch (back) to C for my '816? Nope. There still isn't a good (IMO) C compiler for the '816. Many do exist for the 6502 though which is nice. Unlike that web page there I've no issues with the VBCC licensing either - however the thing that will keep me with BCPL for a long time is the ability to develop directly on the platform. I don't want to cross-compile and download. I want to edit, compile and run directly on the system to hand.

To date, I only know of a small number of C compilers that run natively on the 6502 and none are anywhere near portable - The Orca C compiler for the Apple IIgs - written in Pascal, so first get Orca Pascal ported to your chosen platform, then get C going. Aztec C for the Apple II. There are a couple for the BBC Micro - Small C and one other by Beebug (No sources that I can find). I suspect I could port Small-C but I'm really not sure the effort would be worth it. I'd love to know of any others...

So I'll stick with BCPL for now.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

well worth doing!

Thanks and yes, for me, I did feel it was worth the effort.

It's also made me think about getting the old 16-bit BCPL going (again) on my 6502 system - but the main issue there is that the original sources to the compiler and utilities (along with much other Acorn stuff) were lost in the big Acorn company migration/take-over shenanigans over the years, so all we have is the binaries which still work well, but really only on a BBC Micro, or something good enough (Which my Ruby 6502 board is).

Martin Richards has started to re-create some of the sources to the BBC Micro compiler, etc. but his intention appears to be that they're used to migrate the original programs to the current 32-bit compiler - which takes us back to a cross compilation scenario - the current compiler is a 47KB binary....

So options for a native self-hosting system for the 6502 remain limited to the various Basics, assemblers (that run natively on the 6502), old Acorn/BBC Micro ROMs (I got BCPL going, but failed with Forth and didn't even look at Pascal)

But most folks seem happy with cross compiling which is fine and of-course how we bootstrapped the micros back in the early days (and I still use the ca65 assembler, being currently too lazy to write my own macro assembler that runs natively....

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Ah, you've just given me an idea! We tend to distinguish native compilers from cross-compilers - I certainly do. But also, perhaps we tend to think of native compilers as being very much RAM-based. I think I do.

And back in the days of expensive floppy drives, where a floppy mightn't be present, and a dual floppy setup might be rather unusual, that fits the facts. Not only expensive, but also relatively slow.

But... go back further, to the drum machines, the machines with mag tapes, we saw quite impressive compilers, and often they were multi-pass. (Ref "IBM’s 63-pass Fortran compiler") Much effort went into arranging things so data could stream from the input tape to the output tape with minimal stopping and starting. (Let alone rewinding!)

So... here we are, with retrocomputing, where rather many of us have some kind of flash storage setup - pretty common in the land of Acorn to have an SD Card setup. Uses the original filesystems, more or less, but very fast, and working on floppy disk images.

My idea, then, is to consider a floppy-to-floppy native compiler, perhaps very much a multi-pass one, using RAM for data structures and buffers, but not needing to have the whole program in RAM at one time, at any point of the refinement.

Might that be an interesting angle?

Hi all,
Can I add my 5cents worth?

I too have been looking for a decent "high" level compiler for 65C02 work. So far I've avoided looking at Forth 'cos I'm wary of having to learn YAPL(*)... Having said that I didn't want to learn about SPLD/CPLD - but I was pretty-much forced there also - and in fact I enjoyed the challenge. Back to our biscuits.

I would just love to have the compiler be local, on the 65C02 machine. My conclusions so far are close to those of Drogon. A few attempts at getting a Pascal off the ground weren't conclusive for me.

A few of you may have seen my recent jubilation about Rumbledethumps RP6502 system : it ticks the boxes for many of my requirements, but doesn't have a hosted compiler. It does, however, give access to 64Kb of "extended" memory - accessible to the 65C02 through a special pipeline - as well as file handling on any suitable USB storage device.

So - the above idea is appealing for me. A 65C02 hosted compiler that can access files (perhaps through a standard interface?) and/or extended memory - and that can create the final image to fit in a "reasonable" amount of 65C02 system memory...

Extra questions : do we aim for a "standard" language (ex. C99, or ANSI Pascal, or somesuch) ?
I'm not the best programmer in the world, but if I can help I'd be glad to... once I've got one of my POC platforms to a stable state!

(*) Yet Another Programming Language

_________________
Glenn-in-France

For me, BCPL is a good choice. B, or ALGOL, also good choices! (Edit: also PASCAL)

Absolutely!



I didn't mention Forth earlier - while I have used Forth and been paid real money to write Forth systems I'm not a fan of it. I just don't find it natural for me.

I like Pascal and once upon a time I did a lot of Pascal programming mostly on the Apple II (UCSD P system) but also other computer systems in the early 80s but after exposure to C I didn't find it as useful as I felt it could be for me. I did look at porting the P system, but at the end of the day I guess I wasn't that enthusiastic about it.



Memory might not be the issue - see e.g. Eds comments above. BCPL on the original Beeb worked with some 20KB of user RAM available - 16KB or ROM was the BCPL run-time system and some of the library routines, 14KB or additional ROM was the base machine operating system and often another 16K ROM (overlaid with the BCPL ROM) was the filing system. The BCPL compiler was a 2-pass affair then a separate linker to link in the library routines that weren't present in the ROM. It also features a RAM based filing system on-top of the machines filing systems (disk or network) so it was possible to e.g. keep the program source code in RAM between edits and compiles.

The current BCPL compiler is also a 2 pass thing, but it exists as one larger program. (Actually, I think the latest might even be a 3 pass thing as it does extra syntax checking) however it's the best part of a 50KB binary - fine for an 816 system, not so much a 6502.

Maybe we just need to re-make the BBC Micro... My Ruby 6502 board does run the original Acornsoft BCPL system (and at 8 times faster than a BBC Micro it runs it very well indeed!)




Standards? https://xkcd.com/927/

There is no one size to fit all and I doubt there ever will be. I like BCPL but as the 2nd last BCPL programmer on the planet, I know it's not popular. C is the holy grail and todays thinking and techniques can produce some good code for the 6502.

It should be possible to compile BCPL directly to 6502 machine code though - at the very least it would save that 29 cycles per opcode penalty however it may not be the most optimal code and certainly not the smallest. If the aim is a high speed video game, then it may not be the best, but for operating system style utilities then sure.

And also that - are we making system to play high speed video games, or is snake/tetris good enough? Or are we playing with a "what if" scenario of making a new retro style operating system and utilities...

Maybe we just accept that todays retro-new 6502 systems are to be treated like microcontrollers with external compiling then download and run without even as much as an OS or Monitor on the target 6502 ...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Well the PLASMA compiler runs natively as well as cross compiled. I try hard to keep them consistent and they generate the same binary. The cross compiler does have more capability than the native compiler in that it can compile larger files and also compile inline assembly. With the JIT compiler on 128k machines it approaches native compiled code speeds and is fast enough to implement other languages like Forth and LISP and create hires video games. Space efficient byte code helps and by executing byte code from extended or auxiliary memory frees up more main memory for data than you would normally get without a good amount of work.

But it is completely unique to the 6502 and I haven't actually benchmarked it against natively compiled C code. I think the niche environment will keep it from being used but by a few. And really, who wants to do development on old, slow hardware (besides me)?

Well noted, David! An impressive project - I have to confess it didn't spring to mind (I hesitate to say I forgot)
https://github.com/dschmenk/PLASMA

... now why hadn't I seen Plasma before? Reading through the intro page on Github I'm impressed. I think I'll be trying it out very soon.
(I've edited my reply to be more concise)

resman said ;

Well, me... My goal is to have a stand-alone 65C02 system that is a test bed for many things and isn't *obliged* to have an umbilical cord to be programmed. I've installed the VM and been looking through the examples and the source - but I'm afraid that it has triggered a sort-of "senior moment" (to quote BDD) and I'm now quite lost...

Is there a "how to start porting" hints page somewhere in there ? I don't have an apple. I'm not yet sure for which platform I would be porting to (I want to evaluate the RP6502 system first), but I know that it'll be streets away from anything apple.

What i *have* remembered from my rummaging, is that I do like the language as it is currently. Especially the structures. Oh, and if the structures could be manipulated with the Pascal-like "with <mystructure> do { lots of things }" I'd be a very happy senior

In any case, thanks Dave (resman) and perhaps I could pm you for getting some guidance.

_________________
Glenn-in-France

Hi Glenn-

I'll admit that documentation isn't my strong point I did make a bunch of really bad videos as an introduction: https://www.youtube.com/playlist?list=P ... f4SP2Gw3yU
Following along in an emulator may be the best way to decide if you want to invest the time it would take to port PLASMA.

You are welcome to contact me about porting and setting up a PLASMA environment. I even have a minimal setup up for an Apple 1 that makes a good starting point. There was work done to port the VM to a non-6502 CPU as well. The biggest hurdle to overcome would be the file system support. I chose ProDOS/SOS for the Apple versions as sub-directories makes for a more pleasant experience. There are a lot of support modules and include files needed for development. A flat filesystem *could* work but gets crowded quickly. Luckily other members here have done some nice work in making an agnostic version of ProDOS. There is the possibility to get a nice interactive, self hosted development environment together with a modest investment of effort. And you'd get Forth and LISP for free.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hi all,
@JimBoyd : we all have our valid reasons for doing or not doing something. There is nothing to judge. I know my limited possibilities for learning at my age/state of health. I love learning new things - but learning languages (any languages) has always been just too painful.

I'll let Gordon decide, but I think we've moved too far away from the original topic now.

_________________
Glenn-in-France

I think it's great to have conversations and even when things drift it's still OK by me. (See: the law of two feet) The down-side is that someone might not see posts in one thread due to the title and pass over other posts that they may find useful to them.

Also, I'm away from home right now and the past 3-4 days have been busy for me with local events and now work but I have time this morning to pen more thoughts here.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/