Last visit was: Mon Jun 27, 2022 9:12 am
It is currently Mon Jun 27, 2022 9:12 am



 [ 8 posts ] 
 porting BCPL 
Author Message

Joined: Mon Oct 07, 2019 2:41 am
Posts: 325
Does any body know if a BCPL bootstrap kit is still around for a 16 to 24 bit machine.
I have a 20 bit machine with no software but a cross-assembler and a bootstrap loader.
Ben.


Tue Nov 30, 2021 6:45 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1695
I don't have any specifics, but for reference here are some links

Martin Richards' original and current BCPL site
(contains much by way of explanatory material and code)

Improving the Portability of the BCPL Compiler dissertation by Bob Eager (115 pages, PDF, 1975)

The portability of the BCPL compiler by Martin Richards, 1971 (12 pages, pdf available from the DOI link)

A BCPL interpreter for Amiga contains brief overview of porting approach


Tue Nov 30, 2021 2:55 pm

Joined: Mon Oct 07, 2019 2:41 am
Posts: 325
The BBC micro can run BCPL so I plan to use the emulator here:http://www.mkw.me.uk/beebem/index.html
And software here: https://github.com/LardoBoffin/BBC-BCPL_Overview


Wed Dec 01, 2021 5:17 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1695
Good plan! If you have any difficulty with BeebEm, there's also B-em.
https://github.com/stardot/b-em

(Edit: just for reference, also beebjit)


Wed Dec 01, 2021 7:58 am

Joined: Sun Oct 14, 2018 5:05 pm
Posts: 15
oldben wrote:
Does any body know if a BCPL bootstrap kit is still around for a 16 to 24 bit machine.
I have a 20 bit machine with no software but a cross-assembler and a bootstrap loader.
Ben.


I recently (well, relatively recently) got BCPL going on my Ruby'816 system - that's a 65c816 CPU with 512KB of RAM. The '816 is a 8/16-bit CPU with a 24-bit address bus, however RAM is essentially banks of 64KB. You can form a 24-bit address in some instructions though, but the index registers are only 16-bits wide.

My approach was to write/create a VM/interpreter for Cintcode which is one of the formats the current BCPL compiler will generate. There is also an older OCODE and a newer SIAL which is intended to be translated to native code, although I felt sticking to Cintcode would be more beneficial for me.

So I set about writing the Cintcode interpreter in 65816 assembler - not a trivial task as I wanted to "flatten" the address space, so BCPL programs would see the entire address space as linear rather than segmented. I also opted to create a 32-bit VM as that's what a modern BCPL compiler will generate (although the instructions are variable width and you can make it run in a 16-bit VM as long as you never use 32-bit values in your code - tricky at times!)

My code is currently squeezed into 16KB of '816 assembler although it's really smaller, but I have in-lined a lot of operations via macros to try to improve speed. It's not fast in my 16Mhz system - the effective Cintcode execution rate is in the order of 200K instructions/sec.

Aiming for a 20-bit machine... Tricky, but not impossible, but making sure the compiler never outputted any "load word" instructions might be the issue - although maybe re-writing the compiler... Or emulating the 32-bit Cintcode machine in the native assembler of your 20-bit CPU?

I'd love to make a native Cintcode engine, but that's a little beyond my abilities right now, but who knows.

Cheers,

-Gordon


Tue Dec 14, 2021 12:31 pm

Joined: Mon Oct 07, 2019 2:41 am
Posts: 325
After developling my 20 bit design, I have some ideas for a small 32 bit computer under
fpga emulation. Two 16 bit 2901 alu cards and a card for instruction decode
with 512x8 proms and 82S101 FPGA's, 1 meg memory. The front panel only would
display the lower 20 bits of PC and AC, but ample for program debuging or hardware
testing. I hope to have it finished in a week or two. Then I can use 32 bit BCPL.

What ever I do, I still have the chicken and the egg problem, all I can find
is just BCPL source code, but then I have just glanced at the code.

More that I look at languges, from the 60's and 70's there never was a thing as portable
code. Fortran IV came close, but features had to be removed from machines smaller than
a IBM 360, or a PDP 10. Computers came in three sizes small 18 bits or less PDP 8, big
32 bits or more, and weird, every thing else like a PDP 11, or 24 bit machine.
People developing and using high level languges
had access to 'real' (ibm 360's?) computers and left the 'toys' for the average folk, or students.
Code was mostly portable because they ported to the same class of computers word length
wise, a PDP 10 to a IBM 360, rather than a PDP 10 to a PDP 8.

I suspect a true computer, would be one able to handle any size data. Instructions
would be recusive in the sense they decompose down to what the base instruction set
is in terms memory movement or alu operation.
Ben.


Tue Dec 14, 2021 9:07 pm

Joined: Sun Oct 14, 2018 5:05 pm
Posts: 15
oldben wrote:
After developling my 20 bit design, I have some ideas for a small 32 bit computer under
fpga emulation. Two 16 bit 2901 alu cards and a card for instruction decode
with 512x8 proms and 82S101 FPGA's, 1 meg memory. The front panel only would
display the lower 20 bits of PC and AC, but ample for program debuging or hardware
testing. I hope to have it finished in a week or two. Then I can use 32 bit BCPL.

What ever I do, I still have the chicken and the egg problem, all I can find
is just BCPL source code, but then I have just glanced at the code.


I started with the Linux version - downloaded all the source from Martin Richards web site. This included the manual for BCPL and the cintcode definitions and, importantly a compiled version of the compiler, compiled into Cintcode.

So with the compiled version of the compiler and utilities, I followed the documentation to build the cintcode interpreter and the cintsys front-end which is a command-line program written in C which has the cintcode interpreter built-in. That then lets you run compiled BCPL programs, one of which is the compiler. You compile the compiler as a sort of test (it takes about one whole second on my Linux desktop).

Once I had that, I started on the Cintcode interpreter for my Ruby system. It wasn't straightforward as to boot a compiled BCPL program, you first need to build a run-time environment, shared libraries and so on - the paradox is getting this shared libraries in there in the first place. I originally used a small C program compiled with cc65 to create the initial heap structure for BCPLs getvec() call (same as C's malloc) then loaded libraries and finally my CLI program written in BCPL.

Latterly I replaced that compiled C with a small 65816 program that loaded an image that had enough compiled BCPL in it to do the rest of the bootstrap directly in BCPL.

Some early words on that here: https://projects.drogon.net/ruby816-bcpl/

and here: https://projects.drogon.net/ruby816-sol ... p-paradox/

Going back in-time, I started writing the Cintcode interperter one instruction at a time by writing 'hello world' in BCPL, compiling it on my desktop, looking at the Cintcode assembly output (the D1 flag to the compiler), writing those instructions, trying it, rinse, lather, repeat and eventually I got there. There is a compiler test program that exercises most of them as far as I can tell, so one that passed I was happy. The next stumbling block was making the compiler run on my hardware - that wasn't too bad, so now I can edit, compile and run directly on my system, although it's not fast. I still build the run-time libraries and CLI on my Linux desktop when I have to - it takes a few seconds on my desktop but minutes on the board itself.

So if you can get BCPL going on your desktop then I think you're a good way there. That will at least let you see cintcode then you can concentrate on writing the interpreter for it... OR have it generate SIAL code, then look to write a translator from that to your native machine code.

My next move is probably to stay with BCPL but move away from the 65816 - it's just dead-end from my point of view and onto a 32-bit CPU with more registers - if I can keep the VM's A,B,C and PC registers in real CPU registers then things will go so much faster...

-Gordon


Tue Dec 14, 2021 9:42 pm

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1695
Great to hear the details of that success story, Gordon!


Tue Dec 14, 2021 10:00 pm
 [ 8 posts ] 

Who is online

Users browsing this forum: CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software