[VM] NIP specification version 0.2 (alpha)
David Rush
though it has one glaring...feature. NIP instructions are 16 er...12
bits long. There are four "reserved" bits for which I just can't find
a use. And I just can't seem to squeeze everything down to 8 bits,
either. So for the time being I'm leaving the extra bits as 'expansion
room,' unless someone gets a major inspiration...
And there's no floating point in there, either, but I'm running out of
type space. I'm still working this a bit. Please be gentle, this *is*
an alpha release.
There will definitely be additions for interrupts and inference
operations when I finally figure out a clean design for
them. Suggestions will be accepted for the remediation of serious
bugs.
david rush
-----------------------------------------------------------------------
0.0 Introduction
----------------
This is the specification for the Non-Infocom Platform version 0.2
(alpha). It is a fairly informal specification designed to outline the
intent of the core capabilities of the NIP.
0.1 Conventions
---------------
All diagrams are big-endian. Physical data in the machine is
represented in little-endian format.
1.0 data representation
-----------------------
Data values are represented by machine values which are 1, 2, 4, or
eight bytes in length. Only smallints are represented by values which
consume less than four bytes. Four and eight byte values are encoded
with the least significant bit indicating if the value is a smallint.
If the LSB is not asserted the value is a smallint, if the LSB is
asserted the value coresponds to a more complex type.
non-smallint ::=
<vvvvvvvvvvvvvvvvvvvvvvvvvvv><ttt>1
| <vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv><ttt>1
a non-smallint value. the bits <ttt> encode the ultimate type
of the value.
value ::= <v*>
28 or 60 bits indicating the VM handle for the data value
type ::= <ttt>
3 bits indicating the VM object type detailed below
1.1 data types
--------------
bottom
any under-determined value. bottom-typed values are returned
whenever any VM opcode encounters an erroneous condition.
smallint
an integer whose range is convenient for manipulation on the
native machine hardware.
bigint
an integer of unrestricted range.
string
an unstructured block of memory
dictionary
an association from the unsigned integers to VM values
function
a wrapper for VM executable code
frame
a VM execution context
channel
an I/O channel
2.0 execution context
---------------------
All code executes in the context of the current frame. A frame is
the default mapping from integers (called slot numbers or slots) to VM
values. A new frame is created from information in the corresponding
function header via either the apply or close operations.
Slot 0 is always the function argument.
2.1 function header format
--------------------------
A function header consists of five parts:
initialized slot size info
uninitialized slot size info
initialized slot count
unintialized slot count
slot initializers
2.2 frame format
----------------
The frame format is intentionally left unspecified to allow efficient
implementation on differring processors.
3.0 opcode format
-----------------
Opcodes are 16 bits
6 operation bits (o)
2 operand size bits (s)
4 addressing mode bits (a)
4 reserved bits (r)
Each opcode is followed in memory by the apropriate quantity of either
slot numbers or immediate arguments (as determined by the addressing
mode bits). The size of the argument specifiers is determined by the
size field of the opcode.
opcode ::= <oooooo><ss><aaa><rrrrr>
operation ::= <oooooo>
see below for details
size ::= <ss>
the binary logarithm of the number of bytes used in specifying
all arguments. If the size is less than four (ss < 2), any
immediate non-smallint arguments consume four bytes. If size
is greater than four (ss = 3), any immediate non-smallint
arguments consists of eight bytes.
address ::= <aaaa>
for each bit set in this field the corresponding argument for
the opcode will be interpreted as an immediate argument to be
taken from the instruction stream. Unused bits are
ignored.
3.1 operations
--------------
operation values are omitted in this release of the specification.
3.1.1 general opcodes
---------------------
add int1,int2,int3
add integer int1 to integer int2, putting the result in slot
int3
sub int1,int2,int3
subtract integer int2 from integer int1, putting the result in
slot int3
mul int1,int2,int3
multiply integer int1 by integer int2, putting the result in
slot int3
div int1,int2,int3
divide integer int1 by the integer int2, putting the
result in slot int3
mod int1,int2,int3
add integer int1 to integer int2, putting the result in slot
int3
join str1,str2,str3
create a new string in slot str3 whose contents is the same as
the contents of the string str1 followed by the contents of
the string str2
split str1,int,str2,str3
create new strings in slots str2 and str3 where the contents
of the string in slot str2 consists of the integer int
number of octets of the string str1 and the string in
slot str3 contains the remaining octets from the string str1
find str1,str2,int
puts the integer offset of the string in slot str2 from the
beginning of the string in slot str1 in the integer slot int.
fetch str,int1,int2,int3
puts the integer constructed by retrieving integer int2 bytes
from the string str at integer offset int1 into slot int3. The
bytes retrieved from the string str will be converted to
integer in little-endian order.
cmp eq1,eq2,int
puts one of the integers -1, 0, or 1 into the slot int
if the result of comparing the comparable values in eq1
and eq2 is that eq1 < eq2, eq1 = eq2, or eq1 > eq2,
respectively.
get dict,int,val
retrieves the value from the dictionary dict associated with
the integer int and puts it into slot val
put dict,int,val
takes the value from slot val and associates it with the
integer int in the dictionary dict
apply exec,val1,val2
invokes the function or frame exec with the argument val1,
putting the result in slot val2
close exec,val1,val2,frame
puts a frame in slot frame which was derived from the function
or frame exec by modifying its slot val1 to hold the value val2
store val1,val2
puts the value val1 into slot val2
string int,str
creates an uninitialized string capable of storing int bytes
of data and puts it in slot str
dict dict
creates an uninitialized dictionary and puts it in slot dict
time dict
creates and stores a dictionary in slot dict with the current
time represented as follows:
dict @ 1 = current Gregorian year
dict @ 2 = current Gregorian month
dict @ 3 = current day of the month
dict @ 4 = current hour of the day (0-23)
dict @ 5 = current minute of the hour
dict @ 6 = current second of the minute
3.1.2 i/o opcodes
-----------------
start str1,str2,chan
opens an i/o channel associated with facility str1 which is
associated with the underlying machine name str2 and puts the
channel into slot chan
finish chan
closes the i/o channel chan
in chan,str,int
reads bytes from channel chan up to the maximum allowed by the
string str and puts the total number of bytes read in slot int
out chan,str
writes all of the bytes in string str to channel chan
ctrl chan,dict,val
invokes the facility specific control function for channel
chan using the control information stored in dict producing a
result which is stored in slot val
3.1.3 branching opcodes
-----------------------
If a branching opcode selects a value which is neither a smallint nor
a function value, the current function immediately exits returning the
value selected by the braching opcode. If a smallint value is selected
the next opcode will be fetched from the corresponding address in the
current function. If a function value is selected, the function is
immediately invoked and its result is subsequently returned as the
result of the current function.
ceq val1,val2
if val1 is equal to smallint 0 select val2, otherwise continue
to the next instruction
cgt val1,val2
if val1 is greater than smallint 0 select val2, otherwise
continue to the next instruction
cge val1,val2
if val1 is greater than or equal to smallint 0 select val2,
otherwise continue to the next instruction
clt val1,val2
if val1 is less than smallint 0 select val2, otherwise
continue to the next instruction
cle val1,val2
if val1 is less than or equal to smallint 0 select val2,
otherwise continue to the next instruction
cnt val
select val unconditionally
cbtm val1,val2
if val1 is of type bottom select val2
Dark fiber
>Here we go again. I've decided to submit this for public comments even
>though it has one glaring...feature. NIP instructions are 16 er...12
>bits long. There are four "reserved" bits for which I just can't find
>a use. And I just can't seem to squeeze everything down to 8 bits,
>either. So for the time being I'm leaving the extra bits as 'expansion
>room,' unless someone gets a major inspiration...
>
>And there's no floating point in there, either, but I'm running out of
>type space. I'm still working this a bit. Please be gentle, this *is*
>an alpha release.
>
>There will definitely be additions for interrupts and inference
>operations when I finally figure out a clean design for
>them. Suggestions will be accepted for the remediation of serious
>bugs.
>
>david rush
i read this group infrequently so missed all the previous disscussion,
go easy if i say things that have been hashed n thrashed out a while
ago ^_^
i've written a few 'vm' and virtual cpu's. some of your specs look
'strange' no offense. i assume this is a stack based machine and
not register based?
such things like
>add int1,int2,int3
> add integer int1 to integer int2, putting the result in slot
> int3
seem strange, why not just have add int1, int2. add int2 onto int1.
far less messing around inside the opcodes than having to deal with
three separate entities.
have you looked at the strongarm cpu? its VERY nice. every opcode
has 'flags' embedded into it that pretty much do away with separate
opcodes for branch testing.
>join str1,str2,str3
> create a new string in slot str3 whose contents is the same as
> the contents of the string str1 followed by the contents of
> the string str2
>
>split str1,int,str2,str3
> create new strings in slots str2 and str3 where the contents
> of the string in slot str2 consists of the integer int
> number of octets of the string str1 and the string in
> slot str3 contains the remaining octets from the string str1
"string" opcode? wow. a very high level 'VM' here. sounds like your
making things more complex than need be. the less instructions the
better imo.
hmm from reading it, it sounds like your writing a semi hi level
language with short 3 letter mnemonics than a VM.
anyway, best of luck!!
btw, since your opcodes seem very specific, do you forsee any
problems? i realise you said you have many things to add and so forth.
ja ne!
-df
Dark Fiber <ent...@tig.com.au>
http://homepages.tig.com.au/~entropy
Head honch of the Ed Wood school of FanFic
Sazan Aisu Fanfiction homeroom
http://www.geocities.com/Tokyo/Ginza/7478
David Rush
> i read this group infrequently so missed all the previous disscussion,
> go easy if i say things that have been hashed n thrashed out a while
> ago ^_^
No problem...
> i've written a few 'vm' and virtual cpu's. some of your specs look
> 'strange' no offense. i assume this is a stack based machine and
> not register based?
That's intentionally left unspecified. It's a frame-based machine, but
there's no particular obligation to maintain the frames on the CPU
stack. There's two reasons for this: first, linked frames provides a
fairly clean (IMNSHO) way to implement call/cc (and ultimately threads)
should it ever become desirable; and secondly some current RISC
architectures aren't terribly stack-oriented in the first place. The
frame based architecture is designed to provide the information needed
for a native-code cache or a JIT compiler, should such speed
optimizations be necessary.
> such things like
>
> David Rush <ku...@bellsouth.net> wrote:
> >add int1,int2,int3
> > add integer int1 to integer int2, putting the result in slot
> > int3
>
> seem strange, why not just have add int1, int2. add int2 onto int1.
> far less messing around inside the opcodes than having to deal with
> three separate entities.
Yup, I started with a much more stack based design, but see the above
comments about frames.
> have you looked at the strongarm cpu? its VERY nice. every opcode
> has 'flags' embedded into it that pretty much do away with separate
> opcodes for branch testing.
No, I haven't. Got a URL? I'm very interested in this idea (embedded
flags and per-instruction branch coding).
> >join str1,str2,str3
> >split str1,int,str2,str3
> "string" opcode? wow. a very high level 'VM' here. sounds like your
> making things more complex than need be. the less instructions the
> better imo.
It's a moderately hihgh-level VM. I must confess I have been strongly
influenced by the Smalltalk VMs, which do contain some fairly
hihgh-level concepts. In particular, VM knowledge of fundamental data
types. Strings qualify as one of the most fundamental data types in
IF, if not in general programming. However, I'm not entirely happy
with my string operations. I'm trying to do at least two (or maybe
three) things at once: support a nice string library & parser, and
provide general buffer support for the I/O system. I'm also trying to
make sure that unicode and other non-ascii alphabets work smoothly.
As far as the instruction count the spec still has less than 32 opcodes.
> hmm from reading it, it sounds like your writing a semi hi level
> language with short 3 letter mnemonics than a VM.
Well, yeah. The VM is definitely intended to support a HLL for writing
interactive fiction. This isn't everybody's idea of a good approach to
VM design, but it is mine. (And my theory is: Dinosaurs are thin on
one end, thick in the middle...)
> anyway, best of luck!!
Thanx.
> btw, since your opcodes seem very specific, do you forsee any
> problems? i realise you said you have many things to add and so forth.
Well, modulo my introductory caveats in the spec, I think I covered
the worst issues. That's why I've released the spec for public
comment, because I'm sure I've missed some things.
> ja ne!
mata aimasyoo
david rush
okbl...@usa.net
ent...@tig.com.au (Dark fiber) wrote:
>
> i read this group infrequently so missed all the previous disscussion,
> go easy if i say things that have been hashed n thrashed out a while
> ago ^_^
>
There has been much thrashing. Few things have actually been thrashed *out*.
> have you looked at the strongarm cpu? its VERY nice. every opcode
> has 'flags' embedded into it that pretty much do away with separate
> opcodes for branch testing.
One such thing thrashed was a request by myself for VM resources. This may be
another good one to add to the list? (Even if it's not virtual.)
> hmm from reading it, it sounds like your writing a semi hi level
> language with short 3 letter mnemonics than a VM.
There is considerable debate over what "level" the VM should be at.
> Head honch of the Ed Wood school of FanFic
I hadn't heard of this. I've been thinking of writing an Ed Wood IF.
"Don't mind Lobo. He's as gentle as a kitchen."
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum