PLASMA - a fifth VM for 6502

[BigEd]

Elsewhere, Mike took note of David Schmenck's latest adventure, called PLASMA, which is some kind of virtual machine or programming environment for 6502 - presently for Apple 8-bit machines - which aims to learn from previous VMs such as Java (ported to 6502 by David himself), Pascal, and Forth.

PLASMA - Proto Language AsSeMbler for Apple

Code: Select all

import stdlib
    predef puts
end

byte hello[] = "Hello, world.\n"

puts(@hello)
done

Looks interesting!

Cheers
Ed

barrym95838 wrote:

I just ran across THIS today, from a certainly gifted Mr. Schmenk. At first glance, it seems a bit like an alternative to Forth, with similar performance and footprint, but with a syntax that looks a bit more "C-like". Is this something that you or anyone else here might find to be interesting?

Here's a modestly technical description of what PLASMA is about:

https://github.com/dschmenk/PLASMA

Mike

[chitselb]

This looks pretty cool!

[resman]

I've been spending a bit of effort to organize and clean up the documentation, as well as including a link the the PLASMA KansasFest video. Hopefully this makes PLASMA a little more accessible to anyone who wants to try it out. It has become quite stable and is being used to write the game logic for Lawless Legends: http://www.lawlesslegends.com

There are also some new modules that support the Uthernet cards, a handle based swappable memory manager, and a fiber (non pre-emptive threads) library.

I believe PLASMA has some unique characteristics that make it the perfect mid-level 6502 language. I hope you agree.

https://github.com/dschmenk/PLASMA

Dave...

[BigEd]

That's great - thanks Dave, and welcome!

[Dr Jefyll]

resman wrote:

I've been spending a bit of effort to organize and clean up the documentation [...]

https://github.com/dschmenk/PLASMA

"A bit of effort," he says?! This document is thorough and highly readable -- which, for a subject of any complexity, is saying a great deal -- it's far from a trivial achievement, as any would-be writer soon learns. Congratulations (and welcome!).

-- Jeff

[resman]

Thanks Ed. I've only been lurking here for 10 years - I finally got off my rear and made an account.

Jeff, I admit it was more than a little effort for me. I would rather go to the dentist than write documentation. It is still work in progress, but I sent an email to Brian Kernighan, who's writing style I admire and was trying to replicate, and got a nice note back.

Dave...

[BigEd]

Just finished reading the docs - great work. I notice there's no SWAP opcode - presumably this means that the stack frame and eval stack approach has avoided the need to do a lot of fiddling with stack contents?

I'm just about to watch your PLASMA-hosted presentation at https://youtu.be/RrR79WVHwJo?t=11m1s

[resman]

BigEd wrote:

Just finished reading the docs - great work. I notice there's no SWAP opcode - presumably this means that the stack frame and eval stack approach has avoided the need to do a lot of fiddling with stack contents?

I'm just about to watch your PLASMA-hosted presentation at https://youtu.be/RrR79WVHwJo?t=11m1s

Good eye. Indeed, having a compiler generate the code, and judicious use of local variables, removed the need for a SWAP op. It was originally in there, but as I got better with code generation (mostly with the indirect call), I was able to remove it. Now, if the evaluation stack was to be manipulated directly from the program, ala Forth, it would make a lot more sense to have SWAP and other direct stack ops available.

The operation that I did end up introducing that you may not find in many stack oriented architectures is the 'duplicate TOS to memory' operation. - the equivalent to a store/load of the same variable. I optimized the FOR/NEXT loop to keep the iteration variable on the TOS. The value can be incremented/decremented and compared to the end condition without having to reload it constantly. However, because the iteration variable can be read at any time, I just duplicate the TOS to the variable in memory at the beginning of the loop. You might notice that writing to the iteration variable inside the loop won't actually affect it's value (which is on the TOS). A small price to pay for a faster implementation.

Dave...

[magetoo]

I just watched the Kansasfest presentation a little while ago. Super cool stuff!

One thing that wasn't immediately clear to me reading the documentation was whether the function frames were something that paired with a function definition or a function invocation. Given the comments about recursion, I'm assuming that they are allocated at function invocation, is that correct? (I suppose it wouldn't make sense any other way, but you never know with memory-constrained systems.)

Also interesting, I think, is how object-oriented the architecture seems. Functions look a whole lot like objects, or at least like PostScript procedures, dictionary stack and all.

One of my long-term goals is some day implementing a PostScript-like programming environment, so maybe that's just my bias showing. :-)

[resman]

magetoo wrote:

I just watched the Kansasfest presentation a little while ago. Super cool stuff!

One thing that wasn't immediately clear to me reading the documentation was whether the function frames were something that paired with a function definition or a function invocation. Given the comments about recursion, I'm assuming that they are allocated at function invocation, is that correct? (I suppose it wouldn't make sense any other way, but you never know with memory-constrained systems.)

Also interesting, I think, is how object-oriented the architecture seems. Functions look a whole lot like objects, or at least like PostScript procedures, dictionary stack and all.

One of my long-term goals is some day implementing a PostScript-like programming environment, so maybe that's just my bias showing. :-)

Glad the video was beneficial. KFest is a blast and has some very hard-core technical membership and content. You've guessed correctly regarding the call frames - they are allocated per invocation. I've tried updating the documentation to make it more clear.

As for the object oriented nature of PLASMA, that is probably more of a function (no pun intended) of it being modular and some of the syntax I chose (on purpose) to make it more familiar. There isn't any kind of OO enforcement, but you can fake it pretty well. I tried it with the TCP/IP modules. Hiding the different hardware implementations and state behind a common interface made it clean and easy to write the higher level code.

When implementing a language for the 6502, I've decided that "less is more".

Dave...

[magetoo]

Right, "object oriented" is maybe not the best term. It's not OO in the sense that the language has explicit syntax for creating objects and inheritance, but the runtime sort of smells like it would work for an OO language. (Or maybe that's just me having a stroke.)

What tickled my interest was that the call frames together with the functions can be seen as forming a kind of object, with code and data bundled together. And if frames also have backlinks to their callers, that looks very familiar too; like the instance of a function "inheriting" some context from the caller. Maybe that's more of a functional thing though.

Either way, it's given me some ideas I'll have to think about.