View unanswered posts | View active topics It is currently Tue Mar 19, 2024 2:39 am



Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
 porting BCPL 
Author Message

Joined: Mon Oct 07, 2019 2:41 am
Posts: 581
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
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
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
Profile

Joined: Mon Oct 07, 2019 2:41 am
Posts: 581
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
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
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
Profile

Joined: Sun Oct 14, 2018 5:05 pm
Posts: 59
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
Profile

Joined: Mon Oct 07, 2019 2:41 am
Posts: 581
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
Profile

Joined: Sun Oct 14, 2018 5:05 pm
Posts: 59
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
Profile

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


Tue Dec 14, 2021 10:00 pm
Profile
User avatar

Joined: Sun Dec 19, 2021 1:36 pm
Posts: 66
Location: Michigan USA
Quote:
I recently (well, relatively recently) got BCPL going on my Ruby'816 system - that's a 65c816 CPU with 512KB of RAM.


I had never heard of BCPL until reading this post! I just finished reading the WIKI about the history of BCPL. I'm wondering what you saw as the advantages of porting this language to your project? (I am currently considering doing a port of an established language to my LALU computer.) If you had to do it over again would this be the path you'd take? Thanks! Michael


Sat Feb 18, 2023 10:50 pm
Profile WWW

Joined: Sun Oct 14, 2018 5:05 pm
Posts: 59
mmruzek wrote:
Quote:
I recently (well, relatively recently) got BCPL going on my Ruby'816 system - that's a 65c816 CPU with 512KB of RAM.


I had never heard of BCPL until reading this post! I just finished reading the WIKI about the history of BCPL. I'm wondering what you saw as the advantages of porting this language to your project? (I am currently considering doing a port of an established language to my LALU computer.) If you had to do it over again would this be the path you'd take? Thanks! Michael


It is a high level language that could work in a self-hosted environment on a "retro" system.

Which was my aim - The alternative? BASIC - sure, got that, C - it'll never happen. I'm aware of native C and Pascal compilers for the //gs though - same CPU, but making one run on an alien 65c816 system? Nope. It's cross compiling all the way which wasn't what I was after.

Also - part of my thought process was... I used (and I really did use- wrote 1000's of lines of BCPL back then) BCPL in the early 1980s as a 16-bit VM on an 8-bit 6502 BBC Micro, so why shouldn't I be able to host a 32-bit VM on a 16-bit 65816?

Although while workable (and I suspect you've seen a recent post on 6502.org) it made me fall out of love with the 65816 as a successor to the 6502. Maybe some things should be left alone.

My recent 6502.org post: http://forum.6502.org/viewtopic.php?f=2&t=7500#p98270

Video demo of my system: https://www.youtube.com/watch?v=ZL1VI8ezgYc

If I was doing it all over again - I'd not choose the 65816. There are (and where at that time) far better CPUs... Apple went down the 68K route, Acorn developed ARM and there were other 32-bit CPUs at the time - 80286 for example. Also this thing called the Berkley RISC.. Which is what I'm actually playing with today in the form of RISC-V. I have ported my entire BCPL system over to it. Mostly. I could probably get it mostly going on most nice clean 32-bit CPUs, RISC or otherwise. Just need a nice macro assembler and some time. It only took a few weeks for the RISC-V port and most of that as writing the Bytecode/VM system in assembler. By contrast it took months for the '816 the biggest headache was dealing with the 64K memory banking shenanigans.

Cheers,

-Gordon


Sun Feb 19, 2023 7:05 am
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
> Which is what I'm actually playing with today in the form of RISC-V. I have ported my entire BCPL system over to it

I think this answers the question! BCPL is a sufficiently portable and sufficiently high level language to be a good choice for a machine with enough RAM to support it. (It runs on a VM, generally, rather than compiling down to native code, but that's fine.)


Sun Feb 19, 2023 7:23 am
Profile

Joined: Sun Oct 14, 2018 5:05 pm
Posts: 59
BigEd wrote:
> Which is what I'm actually playing with today in the form of RISC-V. I have ported my entire BCPL system over to it

I think this answers the question! BCPL is a sufficiently portable and sufficiently high level language to be a good choice for a machine with enough RAM to support it. (It runs on a VM, generally, rather than compiling down to native code, but that's fine.)


Yes, that was the crux of it all - I had a binary version of the compiler that ran under a Linux version of the CINTCODE VM so once I'd written the '816 version of the CINTCODE VM then running the binary was easy. (Actually, it wasn't initially, but I could compile stuff under Linux then copy it over to my system and run the same binary there).

Moving it all to another platform was "just" a matter of writing the CINTCODE VM again - it was easier when I moved to RISC-V because I'd done it once before and understood how the ISA of the CINTCODE VM works and because coding in RISC-V was virtually a pleasure compared to the braincell destroying '816 assembler...

By the same token, porting something like Pascal ought to be easy too - Pascal originally compiled into a bytecode - let's call it P-Code, so implementing that ought to make a Pascal machine workable - I have thought about UCSD many times but never really progressed it - mostly because I don't want their "operating system / IDE" - give me a command-line compiler anyday. So to that end I have looked at writing a Pascal compiler to output CINTCODE, but it's low down my to-do list.

Going BCPL to Native - it's possible and the compiler has another output format which is said to be easier to subsequently post-process into native code but I've never really looked. It's possible to translate CINTCODE to native too, but you have to fix-up all the relative branches and function calls. I've not even thought about it as the C in CINTCODE stands for Compact, and compact it really is. The compiler is 44KB of code.

From a speed point of view - it's not fast, but it's not slow either. The cintcode is remarkably compact and has some very high level instructions that map to a good set of native code. Some instructions are effectively variable width (although they have different bytecodes), so for example to load a constant into the register stack (it's a 2-deep stack!), you can load a value from -1 to 14 with a single byte, then load a signed byte with a 2-byte instruction, then a signed halfword with a 3-byte instruction and so on. Stack offsets are similar - a one byte instruction gets you up to 10 (I think) offsets from the stack base - that represents the first 10 local variables in a function - and the compiler will sort variable usage to make sure the most popular ones are in that first 10. Little tricks like that make run-time go as fast as it can.

A lot of the slowness in the '816 version comes from the bytecode byte fetcher and dispatcher. The 816 simply can't handle 8 bit data values well when in 16-bit mode, so I end up doing a 16-bit load (2 memory cycles), masking it with 0x00FF then doing a <<1 and jmp (),x. I could drop into 8-bit mode do the fetch, but then need to switch back to 16-bit mode, still do the mask so end up burning more cycles. The other inefficiency comes from BCPLs desire to have a flat address space and the '816 has 64K banks, so I have to cater for that when a program wants to 100,000th element of an array for example. These sheanigans vanish on RISC-V (and I'm sure most other 32-bit CPUs) making it far more cycle efficient.

But enough for now

Cheers,

Gordon


Sun Feb 19, 2023 5:55 pm
Profile
User avatar

Joined: Sun Dec 19, 2021 1:36 pm
Posts: 66
Location: Michigan USA
Hi, I was browsing the topic of BCPL this AM and found this website with links to an original porting kit for BCPL. I didn't see this link anywhere in the discussion, I apologize if it is a duplicate. BTW: I also ordered a hard copy of the 1980 book "BCPL-The Language and it's Compler", as it looks to be the classic work on the subject. Michael

https://www.nordier.com


Mon Feb 27, 2023 12:01 pm
Profile WWW

Joined: Sun Oct 14, 2018 5:05 pm
Posts: 59
mmruzek wrote:
Hi, I was browsing the topic of BCPL this AM and found this website with links to an original porting kit for BCPL. I didn't see this link anywhere in the discussion, I apologize if it is a duplicate. BTW: I also ordered a hard copy of the 1980 book "BCPL-The Language and it's Compler", as it looks to be the classic work on the subject. Michael

https://www.nordier.com


The canonical site might be Martin Richards own university pages:

https://www.cl.cam.ac.uk/~mr10/

Although that's linked from the site above. It's the place I went to for all my information and so on, although I do have a copy of the BCPL book from way-back when I was doing BCPL in the early 80's.

Enjoy BCPL - share the love ... And you can be the 2nd active BCPL programmer in the world ;-)

-Gordon


Mon Feb 27, 2023 12:12 pm
Profile

Joined: Mon Oct 07, 2019 2:41 am
Posts: 581
I still plan to port BCPL at some point, but still am tweeking the instruction set of my computer and assembler.
Right now I am debugging a version the meta-ii compiler with a symbol table. This means my cross assembler needs
about 24Kb for the symbol table data because of the longer names used. I expect another 24k for the code space since I
have 16 bit offsets for labels.
I have 48kb user space and 32kb kernel space reserved at the moment. BCPL may shoe horn into a tiny space
but other software may need more room.
Ben.


Mon Feb 27, 2023 8:54 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 24 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest


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

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