I know that experience. I wrote my first machine programm on my C64, because I had no assembler.


I want to learn that art. Are there any good books about that? Maybe on https://bitsavers.org ?

I agree.

Those are the reasons, that I am using macros.
Because of theoretical interest, I also want to know how far one can go to create a sort of high-level language with macros in assembly.

You are probably right and operator precedence is not possible in assembly. Macros for RPN on the hardware stack might be interesting for me.

Interesting to know.

That is what I am doing now And in the 80s I spent many nights on my C64 writing assembly without knowing macros or any professional techniques in assembly.
Right now I was stuck at the part, where I wanted to save my X and Y on the stack without overwriting A (not possible without tricks on the NMOS 6502).

Thanks for all your advice.

Hi Gordon,
I am into writing compilers. I am still learning how to do that (parsing is not a problem for me).
If I want something and it does not exist, I can write it. Of course I would not implement Phyton or Java on a 64KB machine. (or 32KW PDP-11)
The clip board on my windows machine has more bytes than a C64 has in total.

If there was more love for Fortran here, I might write a free open source Fortran 77 compiler for the 6502 (or port an existing open source one).
I like Fortran, because it has a clean evolution until today and an ISO standard. It also has a sane for loop unlike C.

I think LLVM is too modern for a 6502 and will generate slow and bulky code - but I might be wrong.

I have some clue how to generate code for a Z80 or 6809 or 68000 when compiling a language of the 60s or later. I would use the stack and some registers for parameter passing and for local variables.

For a limited CPU like the 6502 or something older, it is different.

When I write assembly by hand, I would use similar techniques (calling conventions) that a compiler would use. And I would use macros for repetitive code and label generation.

I will take a look at a-lang.

Well they already exist - to a degree. Python and Java compile to a bytecode - just write the interpreter.

See also: https://github.com/dschmenk/PLASMA

and https://github.com/dschmenk/VM02 (Java)



Yet to some, FORTRANs loops are the work of satan. Some like them, some don't. Be careful what you wish for...

There was a FORTRAN for the 6502 - e.g. https://www.computinghistory.org.uk/det ... I-Fortran/

Why is it not liked today? Lets face it, the 6502 is a hobbyists plaything now. Not many want to code in FORTRAN for fun, so there simply isn't anything new out there now, and what is out there is limited to old platforms.


Many people want to code in C, so there are C compilers - and I have used cc65 - the code it produces might not be the best, but it works and is fast enough - it compiles my nano-like editor (some 1200 lines of C) into about 15KB of code and it runs more than fast enough. Also consider "time to market" where the market here is just us. We're not selling anything. (Well, commander X-16 people may be). So being able to code a game in C and get it out there in days or weeks rather than months of hand-coded macro assembler - bonus. Or just do it in BASIC. Who cares if it's 16K rather than 4K - if it works, and it's fast enough, ship it. It took me an hour at most to get my editor going under cc65 and running on my 6502 system. (It took me a lot longer to write the console IO library for my SBC, but that was a one-off task, after that C programs are compile and go).



I think you may be wrong. From what I've seen it's generating the best, smallest and fastest 6502 code right now. I simply haven't had time myself to look at it, having gone down a different route after moving to the '816 and found that C on the '816 was not going to work well for me.

https://llvm-mos.org/wiki/Welcome



My chosen route for a 60's language is BCPL. It compiles to a fast, efficient bytecode - it runs well on the 6502 (in 16-bit mode - faster than BBC Basic which is already fast), but on the '816 it's still fast in 32-bit mode, but not as fast as I feel it ought to be, however still fast enough and the compiler, written in BCPL can compile directly on the SBC - compiling a 'hello world' program takes under 10 seconds. I can live with that. The same bytecode on RISC-V is very fast and on ARM - greased lightening. (Wish i'd never bothered with RISC-V now)



-Gordon

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

Sorry, my post was no clear. I might write a cross compiler for Fortran or ... BCPL ... in a modern language on a modern OS.
I did not learn BCPL though.
But I might port my future Fortran compiler to BCPL, just for fun.
Wikipedia claims, that BCPL is suitible to write Compilers. I don't see how. And I'd like to see a compiler written in BCPL.

I want to skip that hard part and take the code from some open source Fortran compiler, if possible.
For myself, I need only an Integer-Fortran in the beginning - like Integer-BASIC (without reals or complex).

For fast programs I do not want a garbage collector. This means no Java and no Python.
The Commodore Basic has a garbage collector for strings which is said to be very slow (maybe a bad implementation).

When execution speed is not the first priority, I like bytecode (p-code for Pascal, or o-code for BCPL). I think the Apple Fortran compiler also use p-code, so it could not be super fast.

BCPL has local functions, so I assume it uses the stack similar to Pascal. (It can be slow and can use several indirections. Maybe it is fast on the PDP-11 indirect adressing mode.)

I am looking for a simple and fast language, that fits nicely to the 6502 instructions. (no garbage collector, no recursive functions, no data on the stack)

I'm sure that if you try hard enough you can write a compiler for anything in almost anything. You can even write an operating system in FORTRAN if you try hard enough (Early Primos, and possibly others for example).

The BCPL compiler is written in BCPL.

Get it all here: http://www.cl.cam.ac.uk/users/mr10/BCPL/bcpl.tgz the distribution includes a compiled binary of the compiler, so all you need do is write the bytecode interpreter/vm and off you go.

BCPL is very easy to write code in - it's C without all the fancy types...

-Gordon

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

I took a second look at the DO loop in Fortran77. I do not like the continue statement with a label. Some compilers had a END DO statement (without label), but that is not ANSI. I would strongly prefer that.
At least the DO loop can have zero roundtrip in Fortran77 (not in 66).

On the other hand, I use zero roundtrip loops in assembly when I want to have 256 repetitions.

There are some Fortran compilers on github - even one that targets LLVM. I have to take alook on them.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

No. And right now I've no intentions of. This may change.

Once upon a time I supported open source and released a lot of code that was installed on millions of systems, but the open source "community" let me down to the point where it badly affected my health and when I asked for help... I got nothing. That was nearly 5 years ago though. See https://xkcd.com/2347/

I have published a few things recently under a "source available" license (whatever you might interpret that to be), and I may yet do it for my BCPL system - however it's actually many things and would be quite challenging to port. Saying that I'm now on my 3rd port of it all - '816 to RISC-V and now ARM. It took months to write the '816 version, weeks for the RISC-V and I had the ARM version 90% done in a few days. (but for the ARM version, I already had steps 1 and 2 below from another project)

What's needed:

1. Have a "host" system that does the filing system and terminal IO for you. On my Ruby system this is an ATmega that shares 256 bytes of RAM with the 65'816 in a mutually exclusive manner. (ie. one or the other, not both at the same time - latency is high, but 10s of microseconds not milliseconds) the ATmega code is all in C and I initially started with my own filing system, but moved to an existing FAT32 filing system relatively recently. This also acts as a floating point accelerator. I throw FP operations at it and read the result back.

2. Write an Acorn compatible OS on the '816. Mine is some 10-12KB depending on the platform. This is mostly in 65C02. I wrote this initially on my 65C02 board to run BBC Basic - I can run BBC Basic and some other Acornsoft language ROMs on the '816 board. (I did port it to one other board a while back and added in framebuffer support - not that hard)

3. Port/re-target the Cintcode/Bytecode VM which relies on (2) which relies on (1). This is a shade under 16KB of object code in about 50 files and is assembled using ca65. The OS and Cintcode VM lives entirely in Bank 0. It's near 100% native '816 code. All compiled BCPL code lives in banks 1 upward. Stacks and the global vectors live in bank 0 and are accessed using 16-bit indexes.

4. Then you need the BCPL bootstrap "ROM" This is under 4KB of compiled BCPL code. This loads up the other (shared) libraries, initialises the heap(s). Imps (multi-tasking), and so on. The libraries are some 7.7K lines of BCPL source code and headers over 42 files. Starting (3) causes this to be loaded from filing system in the '816 system, in the RISC-V and ARM versions it's assembled in (as a binary blob) as part of the Cintcode/VM binary it works as if the Cintcode/VM in a real CPU with a ROM. This was my "bootstrap paradox" moment. Initially I fronted it all with a small C program which created the memory segments, and loaded in the code, but I eventually worked out how to write it all in BCPL - one of the first things I needed to do was allocate memory, but the allocated needed to be initialised, but I couldn't call global functions because the global linkage table wasn't populated, and ... Resolved by working out the dependences and working back from there...

5. Utilities - like an editor, compiler, basic commands like ls, dir, copy, mkdir and so on. My editor is about 1700 lines of code (I use blank lines liberally though) It compiles to 5.5KB of binary.

6. Enjoy.

Porting: Well, step 1 and 2 might not be that hard - really a Posix style filing system and some terminal IO is all you need. It's quite filing system agnostic providing it supports long enough filenames. Open/read/write/close is all the OS uses - Utilities might need seek... My RISC-V port was actually an emulator written in BCPL running on the Ruby board... 816 code interpreting cintcode running compiled BCPL emulating RISC-V running a cintcode emulator written in RISC-A asm running compiled BCPL code... It worked surprisingly well, if a little slow... (My RV emulator was running at about 2K instructions/sec) I have run it on real RISC-V hardware, but lacking steps 1 and 2 all I could do was bootstrap the "ROM" and get it to run a mandelbrot included in the ROM as a proof of concept it was all working.

Step 3 is the crux. I'm on my 3rd CPU now - good macro assemblers are needed. The RISC-V version is some 11KB and the ARM version 10KB (whoever said moving to 32-bit systems would bloat binary size was wrong - at least in this instance - however having native 32-bit arithmetic operations and word fetch/save does go a long way)

Steps 4, 5 and 6 - these actually port well at the binary level! I've not had to re-compile the library, CLI, utilities to move these between platforms (other than for some debugging).

I liked RISC-V - it's simple to learn and use. ARM is more complex to learn, but has the ability to combine operations which RISC-V can't. The core of the system is the bytecode fetch and execute - this in in-lined with every one of the 256 possible instructions - it doesn't have to be, you can JMP/JSR but that adds time (but saves huge RAM) and when the fetch/dispatch code takes 29 (or sometimes 37 cycles, saving a cycle or 3 matters). ARM does it in 2 instructions.

(And for those who care, I think RISC-V will catch-up with ARM, but ARM has a 30 years and billions of $ of investment headstart)

Here is a comparison:

https://unicorn.drogon.net/nextOpcode.txt

and here is the code that handles the AP bytecode - this takes a single byte parameter which is the offset in the stack of a local variable - AP is add local variable into regA (The stack Pointer is P) - noting that BCPL is word orientated so e.g. local variable 4 is 4 words offset from the start of the stack - ie 12 bytes, so the shifts are needed...

https://unicorn.drogon.net/addLocal.txt

and if anyone wants an example of a largish BCPL program then:

https://unicorn.drogon.net/edit.b.txt

is my editor...

Cheers,

-Gordon

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

It's a bad implementation.

However, BASIC does not need to garbage collect. My BASIC written in C doesn't. It does have the advantage of a very high performance memory allocator though - the old (Microsoft) 8-bit BASICs didn't and had real memory constraints which didn't help. There is no re-use of "free" string memory until you force it to garbage collect - this can take minutes.. A loop adding characters to a string can very quickly use up RAM if you're not careful.



BCPL uses a stack but it's not the stack that makes it slow (relative to native ASM). The compiler outputs instructions like "fetch local variable 5 from the stack" and this takes one byte. Fetch local variable 256 needs 2 bytes but the concept is no different from C. Pushing variables into the stack to call a function is simply store variable at current stack plus offset needed for the current function plus offset for the parameter in the called function - the compiler works that out and emits a single instruction, then the call adds the stack used by the current function to the stack pointer and calls the function... It seems like a lot to do, but the compiler is doing most of it. The bytecode VM only has 2 registers and they sometimes work like a stack - fetch value into A, fetch value in A (A is copied to B), Add A := A+B and so on. so the compiler does the expression evaluation and the cpu just executes it, but with just 2 registers, memory pressure is high.



It's like the old saying: Pick 2; Simple, Fast, Cheap. you only get 2... Try Apple Integer Basic, Atom Basic, or (my) TinyBasic (not fast though) Not sure if anyone has ever ported Atom Basic though... I reckon that if you can write a fast moving platform game on the NES in C using LLVM then that's where it is at though.

Or if you want to see what can be done in BCPL on a 16Mhz 65816, then:

https://www.youtube.com/watch?v=ZL1VI8ezgYc


-Gordon

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

Thank you. I took a look at llvm-mos and watched the video. They are using a lot of tricks, including static stack allocation (this is what I need) and virtual registers (this makes the modern code generator happy).

They have a front end for Rust and for C99/C++11. I should give that a try.
Recently I started to learn Rust. It is a good replacement for C in my opinion.
If I use C, I must create a lot of C macros to make it look like Algol/Pascal/Modula. Otherwise it would be horrible for me.

A Fortran frontend for LLVM should also be possible.

I finally read https://dwheeler.com/6502/a-lang.txt until the end.

I thought, it would implement a language. My fault, not reading your text carefully.
And yes, I already read some parts of it before.

I have seen an Algol60 compiler written in Algol60 - not easy to understand for me.
I have seen a Pascal compiler written in Pascal - horrible code with variant records - it took a long time for me to understand.
This gives me an impression, how people in the old times wrote compilers in old languages. (Fortran-I was the first, that I consider a programming language).

Can you point me to any information about Primos? I could not find one on the internet. Is it like Unix or like Tripos/RT-11/VMS?

Thank you. I am very eager to see the code.

I love types and I hate C
I hope BCPL is more like Algol without types. Maybe like Algol58?

Most Pascal compilers are/were written in Pascal. I was slightly fond of it for a while and even made good money writing code in it, but not today.



You "bootstrap" the compiler by writing the first one in assembler. It might even just be able to compile a subset of the language. You then re-write the compiler in this language (or subset). Compile that with the assembler version, then use that to compile itself. Compare outputs,debug, etc. re-iterate this loop until you have a compiler written in itself that can compile itself. I suspect modern FORTRAN compilers (for Unix) are actually written in C or C++ now though.

OR... You write the first iteration of your language in another language, then use that to compile your target language, then (re) write the compiler in your target language... C was developed this way. They used BCPL to write a compiler for a language called B, then used this to write the C compiler, then compiled the C compiler with itself, eventually.

Of-course you need a working BCPL compiler to start with, but that was easy - it outputs an intermediate code, so just write the interpreter (bytecode VM) for that code and use an existing binary...




There's not much there now - mostly because they were run of the mill (if somewhat poor performing) "mini" computers in the late 70s and early 80s. Primos was a command-liney sort of thing but lacked the niceties of Unix. I had no enthusiasm for them when I was at uni. (mostly because the people running them didn't encourage it and I'd discovered Unix and C and other things more interesting to me) We had one (then several) at the uni. I was at (1980+) I think the most exciting thing I did with it was write a shell sort in PMA (Prime Macro Assembler)

https://en.wikipedia.org/wiki/Prime_Computer



See the example I posted earlier: https://unicorn.drogon.net/edit.b.txt

The classic Hello World (which was first written in BCPL by some accounts):



Maybe stick to FORTRAN - remember a good programmer can write FORTRAN in any language... (and fall down this rabbit-hole if you dare)

http://www.matthewsworkbench.com/writin ... -language/
https://hackaday.com/2016/12/27/fortran-for-the-web/
https://blog.codinghorror.com/you-can-w ... -language/

-Gordon

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

That was funny I have never heard that before.

My main languages are Kotlin and Java. My first language was Algol60 (and Pascal my second).
Fortran is the minimal viable programming language for me. I wrote only one Fortran programm in the 80s, because the computer had no Algol compiler.
I am using C(++) for AVR and ARM-Cortex programming, but I hate it. I started to use Rust on ARM (Pi pico) now. Maybe it works on AVR too.

BCPL looks half like Algol and half like C to me. At least it has a sane FOR loop - unlike B and C.

On the 6502 (not 65C02, not 65816) I would like to use some kind of Fortran or compiled BASIC or Rust with llvm-mos for fast programms.
For slow programms: BASIC (interpreted), Pascal (p-code) or any JVM language (bytecode).

My favorite OS is still Amiga-Dos(Tripos). It was written in BCPL by the way.