ytropek wrote:
drogon wrote:
RISC-V I found to be the easiest. Actually all the RISCs were relatively easy althogh ARM has changed a little since I first wrote code in the beginning to what it is today.
Sparc has their interesting register window thing, i860 is a nightmare if you want to do floating point. Transputer is like nothing else, Prime is best forgotten and the INS8060 (SC/MP, etc.) is nice but takes a lot of work. (Similar for the PDP-8 and Eliot)
The most human friendly? CESIL. Maybe LMC. But they're not real...
Wow - I'm deeply and honestly impressed with your enormous experience!
It's just an age thing...
Quote:
I'd be more than curious to listen to your stories about these machines and low-level coding on them. Among all - I am the most curious about your experience with Transputer. I, unfortunately, never had any chance to deal with it, but it was always fascinating me. If I remember correctly, the authors first created the language (Occam) to program Transputer, then the compiler, and based on that they figured out the minimalist instruction set to drive the machine. I really liked that design approach. If you don't mind - could you share a little bit more about your Transputer experience. Have ever had chance to deal with Atari Transputer workstation?
I worked for a UK supercomputer company 80s/90s - they were founded by some of the people who founded Inmos, so there was a very close connection. The Transputer instruction set - which itself has an uncanny resemblance to the code produced by the BCPL compiler which is unsurprising as they all came from Cambridge where BCPL came from... OCCAM was just one language for the transputer - I coded mostly in C.
The way my task scheduler works in my '816 system is quite similar to that of the Transputer (which has a task scheduler in its microcode).
My work as mostly in the R&B department helping engineers test new boards (I wrote all the test/diags for new transputer boards) then turned that code into drivers an utilities for the applications guys. We did some very custom boards for some weird hardware we were interfacing to...
Quote:
Never heard of CESIL. Could you share what makes it, in your opinion, one of the most human friendly ones?
It's a made-up one (like LMC). Designed for school kids to write programs on coding forms, send them into the local computing centre and have the results passed back a week or 2 later. It was just before the advent of computers in schools (In Scotland at least, so early-mid 70s) I wrote an interpreter and run-time for it in BASIC some years back:
https://projects.drogon.net/cesil-contr ... pberry-pi/Same for LMC:
https://projects.drogon.net/lmc/Quote:
drogon wrote:
I'm not sure assembly coding is ever human friendly - some are easier than others, but it's a means to an end at the end of the day. I do feel we should strive to get the high(er) level compilers to do more work for us - buuuut ... to do that then we still need people who can understand how bits of the underlying architecture work at the machine code level - at least until AI catches up...
From pragmatic perspective you are absolutely right. This is why RISC took ever at some place, as it was easier to produce compiler-generated (and optimised) machine code for such machines. Yet, at least in terms of hobbyist projects, there is some kind of pleasure or even magic to deal on such a low level.
drogon wrote:
After spending a lot of time being frustrated with the '816 (mostly it's 64K banks which I didn't want my applications to know anything about and one particular inefficiency regarding reading an 8-bit value when in 16-bit mode) I re-wrote my entire project (a bytecode/VM to run my multi-tasking OS written in BCPL) in RISC-V which was a delight to do.
I'll take is a warning as it looks like I'm at the beggining of the same path (writing multitasking OS for '816), and perhaps before stepping any deeper I should learn from your experience...
It all depends on what you want - if you want a platform where applications can live inside a 64K bank and access up to 64K of data then its relatively easy - accessing more than 64K starts to get harder, but it's by no means impossible. My aim was for a self-hosting system - something I could run the compiler, editor, etc. directly on without resorting to cross compiling. The way I achieved that was to pick a relatively easy compiler to get going - BCPL - and that compiled into a bytecode, so step 1: Write the bytecode VM. BCPL has no concept of segmented memory, so the VM had to "linearise" the underlying memory so I can allocate an array 100KB long in BCPL and it will "just work".
When I wanted to move on, I wrote a RISC-V (RV-32IM) emulator in BCPL then re-wrote the bytecode interpreter in RV assembler and successfully bootstrapped my BCPL OS under the emulator. It wasn't fast, but it worked well enough to enable me to get it going on an ESP32-C3 system. (Which might fit my needs it if just had a little more RAM)
Quote:
drogon wrote:
all I need to do now is find the right RISC-V platform to use which may well end up being an FPGA but that's for another place...
Have you seen Milk V (
https://milkv.io/)? Very interesting platform...
I've seen many - the issue is that broadly speaking they fall into 2 categories: One is the "microcontroller" types - a few 100 KB of flash and a few 10s of K of RAM... OR many MB -> GB of RAM, 64-bit, multi-core designed for Linux. There are very few ones in the range I want for a hobby project - so that same few 100KB of Flash but 0.5 to 1MB of RAM and easy to use peripherals. Everyone wants to cram as much as possible, so you end up with Wi-Fi, AI, Encryption, USB systems on the chip which then makes it as hard to write a bare-metal thing from scratch for as the Raspberry Pi (Which I have done).
Cheers,
-Gordon
_________________
--
Gordon Henderson.
See my
Ruby 6502 and 65816 SBC projects here:
https://projects.drogon.net/ruby/