1
0
mirror of https://github.com/dschmenk/PLASMA.git synced 2024-06-26 06:29:28 +00:00

Updated Porting Guide (markdown)

David Schmenk 2018-02-03 09:38:41 -08:00
parent fe4aea42ff
commit 413c2d4cff

@ -32,8 +32,9 @@ One of the objectives of PLASMA was to ease the programmer burden for routine us
Due to these features of the language, PLASMA will be a natural fit for CPUs that can perform 16-bit internal operations and can address byte locations in memory (odd -or- even address) using 16-bit addresses. Of course, the PLVM must be reimplemented for the CPU, but would theoretically result in a more streamlined VM since some VM opcodes would be much more trivially performed by the 16-bit CPU compared to a 6502. If only PLASMA language portability is necessary (no PLVM byte code portability), then it may even be practical to compile PLASMA directly to the 16-bit CPU's native code so it can be executed without an interpreter. However, at this point one must ask what benefits PLASMA offers to the 16-bit platform, alongside the likely existing high-level language compilers for C/C++.
The [65802/65816 VM](https://github.com/dschmenk/PLASMA/blob/master/src/vmsrc/plvm802.s) demonstrates using a 16 bit CPU and the hardware stack for expression evaluation yet retaining compatibility with external 8 bit code and interface of the 6502 VM.
There is a somewhat raw implementation of the PLASMA bytecode interpreter (no "cmd") for the homebrew 16-bit OPC6 CPU discussed here: http://anycpu.org/forum/viewtopic.php?f=3&t=426 This implementation doesn't have the latest VM opcode changes, so you must use a version of the PLASMA compiler from the same time as the thread posts. (It would be possible to implement "cmd", but this requires a fuller OPC6 environment with terminal I/O and random access files, which the basic OPC6 emulator lacks.)
## Potential for incorporating ports in mainline PLASMA project