Byte code interpreter

_djm

I'm looking to run some code on an SX52 external to the onboard 4K ROM. As I know this can't be done natively, can anyone point me in the direction of·any examples where this has been done previously.
I'm happy interfacing to an EEPROM and copying the code from EEPROM to some SRAM for speed of reading but I have no experience in how an·actual byte code interpreter works.
I don't want to run code that resembles a high level language. As close to the SX assembly as possible would be my preference.

Paul Baker

Byte codes are most efficiently implemented using a jump table in SX using jmp pc+w. Because two instructions are needed for each entry (the first being a call instruction, the second being an escape command (jmp or ret) so you dont execute other command entries, you would fetch the byte code from the external memory, and shl the byte code before doing the jump into your table. This provides you 128 possible commands.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Peter Verkaik

The closest to sx code would be for you to download a SASM generated hexfile into eeprom
and parsing the eeprom data in your bytecode interpreter.
A jumptable would be fastest:
Call routine byteinterpreter from your program

org $200 ;best to start at page offset
byteinterpreter:
add pc,w
jmp code0 ;all coderoutines exit with retp
jmp code1
jmp code2
etc.

regards peter

Paul Baker

Ah yes, forgot about the one call/multi return trick. Its been a year or so since I looked at my forth interpreter. Thanks Peter.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

_djm

Simpler than I thought, thanks, I'll give it a go.

Peter Verkaik

To show what would be required, here is a list file I digged up.
This one is created by the Retargetable Small C Compiler.
Wether you parse bytecodes from smallc or a sasm hexfile,
the parse loop will be most identical, only the runtime routines change.
You could interpret multiple sx28 programs using a sx48 when you
use the rambanks only present in the sx48 for the bytecode interpreter variables.

The listfile was generated for the accompanied c file.
Note that the bytecodes are stored in rom (dw statements), so SASM resolved
all label references, something much harder to do without sasm.
The parse loop starts at VM_main.
You can open both files with notepad.

regards peter

James Newton

Peter, that is really quite an impressive amount of progress that you have made with your port of Small C. The fact that it could support bytecode interpretation from internal or external memory is exciting. Especially when combined with the ease of configuring the virtual peripherals that your methods allow.

I have long believed that the ideal language for the SX would allow for code to be written in two modes: Direct or translated into asm to run in the chip at high speed (especially for virtual peripherals) and also translated into byte code for slower execution from external memory.

Imagine the ability to take ONE development board, then select what virtual peripherals you need and load them with an interpreter and perhaps some small amount of time critical code into the chip, then load your over all control program into the external memory. Like a STAMP, but with the ability to change the VP's and to include ASM in the chip.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james at sxlist,com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!

Peter Verkaik

Hi James,
Running from external memory is not that simple because then all references
must be resolved without sasm. Parsing a sasm hexfile stored in eeprom
already has the references resolved, but the biggest problem there is that
all system registers must be kept as shadow registers that must be updated
after each sx assembly instruction to reflect the correct status.
The smallc machine cpu only has 2 16bit registers and a stackpointer and a
program counter which gives it a very small memory footprint.

It is possible to run normal mainlevel code and executing the bytecode
interpreter by rewriting the vm_main loop as a subroutine that only
executes 1 bytecode sequence. There currently is a great dependance
between the c source and the required assembler files.
Small c has no knowledge of ports and interrupts. There are however
builtin keywords for concurrency but I have not yet tried those out.
I programmed my own interrupt scheme which also works fine
but these are not deterministic.

regards peter

Peter Verkaik

James,
I managed to resolve address references without sasm.
Basically, a small c program only consists of rom (the program and initializers)
and ram (variables, heap and stack), both areas may not overlap.
I use the M4 macro processor as a two pass 'assembler' that generates
a list of byte values.
It is up to the interpreter to remap memory areas into builtin memory,
external memory or ports.
The only glue logic is a BIOS call with a 2 byte operand.
The order in which files are generated:
c source (testgen.c) compiles into testgen.m4
M4 then assembles testgen.m4 into testgen.txt
This testgen.txt has quite a lot of blank lines that I
remove with a utility with testgen2.txt as result
pcodedef.txt holds the pcode definitions.

Now I will·write an interpreter for the javelin
(so when sx/c comes along I can port that to the sx).

regards peter

Post Edited (Peter Verkaik) : 4/1/2006 11:02:03 PM GMT

PJMonty

Peter,

You're a freak of nature - and I seriously mean that as the biggest compliment I can think of. You're just a hardcore, programming freak. Keep it up, you're like some sort of gold standard around here.

Thanks, PeterM