
MPL – Motorola's M6800 Programming Language - jhallenworld
https://github.com/jhallen/joes-sandbox/tree/master/exorsim/mpl
======
RodgerTheGreat
If you're interested in languages like this, often called "High-Level
Assemblers", you might be interested in L.in.oleum[0], a portable assembler
designed to aid the creation of a sequel to the game Noctis IV, or Octo[1], a
purpose-built HLA I designed targeting the Chip8 virtual game console.

[0][http://en.wikipedia.org/wiki/Linoleum_(programming_language)](http://en.wikipedia.org/wiki/Linoleum_\(programming_language\))
[1][https://github.com/JohnEarnest/Octo](https://github.com/JohnEarnest/Octo)

------
fit2rule
The idea of conforming a language specification directly to the constraints of
a platform is highly idealistic, of course, but nevertheless one which has a
lot of contemporaneous applicability. Yet, the vogue appears to be more
inclined towards abstraction. Here, we see the abstract in its most naked
form: the owner of the hardware is the same as the owner of the software. They
are the first user.

So this is quite a poignant item for the HN crowd. Do we need more, or less,
of this sort of thing? Methinks, more.. but it may be knee-jerk borne from a
few decades of jade.

~~~
ajross
I'd say not idealistic at all, it's an entirely practical thing. Early LISPs
were coded directly to the instruction set and register widths of the 36 bit
IBMs they were written on. BCPL and B were likewise untyped languages with the
"word and pointer are the same thing" assumption baked in. Fortran and the
IEEE floating point standard evolved in lockstep, etc...

------
jamii
This is wonderful work. I wonder how long it will take for software archeology
to become a real field? So much is forgotten already.

~~~
jeffreyrogers
I often wonder about how much programmers of my generation are missing out on
because of our relative lack of understanding of the full stack of software
and hardware. Many of my peers have never written C code outside of school and
largely expect to only work in high level scripting languages like Python or
Ruby.

~~~
rubiquity
> _high level scripting languages like_

I'm sorry, I thought that term died a long time ago. What exactly is a
scripting language to you and how is it different than whatever you may call a
"normal" programming language?

~~~
cogburnd02
Basically perl, Python, sh/bash, and so on. Not C or C++. (Well, there's
'#!/usr/local/bin/tcc -run' [1] which can do C but, you know, that's the
exception to the rule.) Moar here: [2]

[1] [http://bellard.org/tcc/tcc-doc.html](http://bellard.org/tcc/tcc-doc.html)
[2]
[http://en.wikipedia.org/wiki/Scripting_language](http://en.wikipedia.org/wiki/Scripting_language)

~~~
rubiquity
That's insane. Perl and Python are both general purpose programming languages.
This reminds me of the days Java developers used to call Ruby developers
"script kiddies."

So if C and C++ are the only true programming languages, we're all just script
kiddies? :/

~~~
cogburnd02
No. I didn't say anyone was a "script kiddie." I merely stated that _the
manner in which Perl and Python function_ is different than _the manner in
which C and C++ function_ and that's enough of a difference that they belong
in two categories of languages: 'scripting languages' (which are not compiled
to assembly and typically require an interpreter) and 'compiled languages'
(which can be compiled to assembly and typically do not require an
interpreter.) Nor did I say Perl and Python aren't suitable for general
purpose tasks. If you think 'using a scripting language' is the same as 'being
a script kiddie,' then you're just wrong. [I don't know enough of how Java or
Ruby function to say which category they belong in.]

------
tacos
> ! is special also, use !! to get !

The exclamation point forces direct addressing in the 6800 assembler. I can't
believe I remember that.

------
diydsp
Awesome work, Joe!

------
kjs3
Playing with some hd6303 from the parts bin makes this _very_ timely.

