L65, a structured language instead of an assembler

Inspired by the latest work of Niklaus Wirth, his PICL language. I am thinking of designing a new language for my 6502 based machines.

Programming the small 6502 machines, like the KIM-1, Micro-KIM or the Apple 1 replica’s for applications suitable for this kind of computer, like I/O contriol and not the generic workstation personal productivity, is either done in higly inefficient Basic or Pascal, with lots of unnecessary overhead or via assembler.

The issue here is, that high level langauge are too far removed from the actual CPU. And assembler is the worst kind of programming language thinkable (yes even worse than C).

So the PICL report made me think again on a programming language, based on the structured concepts in the Wirth tradition but close enough to the hardware to replace the assembler. In fact, I would like a language just as powerful as assembler but without the tedious instruction by instruction programming, no type checking, no data hiding, no structure. But the langauge should be able to precisely control the resulting code and data placement. Resulting code must also be ROMmable, very compact, requiring no runtime and the language itself will not put demands on hardware like a keyboard or display.
Buidling libraries (modules) will do for that.

At the moment I am writing a language report and thinking of code generation and how to add modular programming concepts.

What I can think of already is:

  • syntax like Pascal
    – IF conditon THEN .. ELSE
    – WHILE .. DO
    – CASE (jumptable or if then else code)
  • operators as usual, not the cryptic PICL choices
  • basic data types byte (0.255), word/address (0.65536), char (ANSII, ordinal values 0.255), string (lengthmax 255 with byte preceeding characters)
  • records and arrays
  • no subranges
  • sets (byte)
  • no recursion
  • functions and procedures
  • value and variable parameters, passing via A, X, Y register or zero page pointer
  • local variables, stored at location in zero page or data segments, freedom in location
  • access to I/O registers (memory based, bit based etc)
  • interrupt handlers for NMI and IRQ and RESET
  • type casting
  • I am not sure about:
    – integers
    – longwords (24 or 32 bit)
    – pointers
    – inline assembler code (handy, but not in the spirit of the language)

Code generation is something to think about. It is tempting to generate assembler code and leave binary code generation to an assembler. That makes it possible to ‘include’ assembly code and have ‘inline’ assembly code. Anyway, no recursion means no demands on stacks for variables, but static assignment only.

Of course the implementation of L65 will be in (Free)Pascal. A cross compiler, console based in my first attempts. And in the Wirth tradition, a hand-crafted recursive descent down parser.  A small language, so a small compiler also. And readable, I really don’t like what Wirth has done in PICL with expressions.

Something to think about during the vacation in Jordan! Lets see how the desert inspires language design.

Ah, and read this: Wirth on the current state of Informatics

3 thoughts on “L65, a structured language instead of an assembler

  1. Dear HansO, you have a great ideas with this language. And only one question – why not Oberon-2 or Component Pascal? I think this languages absolutely accept your ideas. And you can develop for 6502 machines in Oberon-2 (with help of port of optimizing Oberon-2 compiler (http://ooc.sf.net) to NMOS 6502 platforms using cc65 (http://cc65.org) as a portable assembler). Also you can try Lotta language (http://lotta.sf.net).

    I invite you to Oberon forum – http://zx.oberon2.ru/forum , if you like – to discuss 6502 specific questions. I am not especially interested in 6502 machines, but I’m interested in modular languages and development in Oberon! I have develop cross-platfrom Oberon-environment XDev that may be used for development for 6502 too (now it is used for ZX Spectrum and CPU Z80). Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *

*