[REBOL] Re: you'll think I'm crazy, but...
From: chaz:innocent at: 29-Oct-2000 13:45
Not a crazy thing at all.
A person (Marcus Petersson <[d4marcus--dtek--chalmers--se]>) on another mailing
list that I subscribed to (KOSH - Kommunity Operation System and Hardware)
has created an implementation of the KOSH Simple Virtual Machine (SVM) in
REBOL. Its "assembly language" is a REBOL dialect.
This is from his readme
Put the files wherever you want. Start Rebol.
Type "do %svm.r" including
relative path to load svm.r.
are (ATM) four user functions. Although nothing stops you from
other functions or variables, you shouldn't need to. Since
everything is packed
within one large object, you will have to precede
every command by "svm/".
Prints a nice table showing the
contents of all registers.
Reset all registers to
The main function. Trims the code and parses it. It
is used by parse-file, but
you can use it directly. The input should be a
string containing at least one
correct instruction. If parse-i finds a bad
instruction, it stops and reports
the name. Not very helpful I guess, but
it will do for now. Otherwise it runs
until the end and says ok.
syntax of the instructions (Rebol is case-insensitive by default):
operands (opt data)
Operands are on the form $0 up to $f. Data is
on the form #0123cdef for hex, or
19123695 for integer. For example:
ori $4, #00000066
notand $9, $6
addi $1, $0, 20
$e, $e, #00000002
mod $4, $b, $0
Wants a filename as argument. This file is read and passed
as a string to
parse-i. Example: "svm/parse-file
Wants two filenames (infile outfile) and an integer
(times) as argument. The
infile is read and copied times times to a buffer,
which is then written to the
outfile. A large file of code can be useful to
test the speed.
There are 7 instructions that aren't handled:
tls and tlsi: Because implementing binary data types in Rebol is
tls, loadi, load, storei, store: Needs some form of simulated
memory. It would
be cool to read instructions (in binary form) from the
memory as well. This
also require a pc and an instruction fetcher and
branch: Also require memory and pc.
The memory concept is
interesting. The parse function would, instead of running
directly for asm, translate them from asm to binary format.
function, possibly the memory handler, would load the code into the
Then a decode function would fetch and decode the binaries from the
which is pc's value. One function could run the code continously,
another could step through it. Supposedly you could read and write
to disk too.
After all the above works, perhaps we could
simulate cacheing, virtual memory,
interrupts and timers. Then we could
build a bus, and hook some simulated
hardware to it. Maybe we could let a
Rebol/View window change colors according
to the data in the "graphics
Plenty. If you follow the usage guide, I hope you
won't trip over too many.
Here's his response to my suggestion that he post it here.
on Sat, 28 Oct 2000, chaz wrote:
> This is great! Makes one wonder what would happen if you added a little
> introduction to the aims of kosh, and crossposted this to
Uhmm no. This certainly isn't anything that would interest people in
general. Not to metion I would get bashed, first for crossposting, then
for writing lousy Rebol code. :-(
If you're interested, you can contact him directly or subscribe to the KOSH
To subscribe to the mailing list, send a mail to
as the only line in the body. You will then receive an authorisation mail -
reply without changing it. You're subscribed when you receive the list
At 12:33 PM 10/29/00 +0000, you wrote:
>I was wondering if it would be possible to create a sparc assemby dialect
for rebol. It would be useful for prototyping assembly code for my assembly
class (without need a sparc machine or assembler).