November 1998
- ADMIN: Unsubscriptions J C Lawrence
- ScryMUD [CUSTOM] Code release. Ben Greear
- Designgoals for CoolComponentCore(Was MUD-Dev's...) Ola Fosheim Grøstad
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Niklas Elmqvist
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Ola Fosheim Grøstad
- DevMUD: CVS Tree is ready. Are your sources? J C Lawrence
- DevMUD considerations and the Halloween article J C Lawrence
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article Adam J. Thornton
- DevMUD considerations and the Halloween article J C Lawrence
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article David Bennett
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Marc Hernandez
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Vadim Tkachenko
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Ola Fosheim Grøstad
- DevMUD considerations and the Halloween article Chris Gray
[Jon Leonard:]
>What sort of environment does it need? That's probably a good place to
>start with for figuring out what the "standard" DevMUD VM interface is.
The MUD language it is for is mostly just a real simple strongly typed
structured language. References from a chunk of code to other things
is done via 32 bit "references", which are typed database IDs. A few
of those are reserved for "builtin" functions contained in the MUD
server, like 'SubString', 'Length', etc. There are over 300 of them,
since a lot are used to do the multimedia stuff. They are used for all
"input/output" that the language has. I did some simple optimizations
like having special bytecodes to push/pop locals at small offsets, and
to push small constants. As I mentioned in an earlier post, it does
run-time code modification. E.g. the first time a call to a builtin is
executed, that call is replaced by one with a different opcode, and the
'reference' to the builtin is replaced by the address of the native
code for the builtin. Such changes are never saved to the database -
the original code is reloaded if the in-memory copy is ever purged, or
needs to be redone for some reason. There are a bunch of branch
instructions, a bunch of arithmetic/logical ones, some string comparison
ones, two special forms of case (switch) statements, and a dozen codes
for database access. Delete the codes for database stuff, change the
string stuff to whatever semantics is needed (mine is copy-on-reference,
with bunches of special cases to reduce it), and do something with the
references, and it could run anywhere.
Execution is just a big case (switch) statement, with icky hand-done
code for the various instructions. There is a symbolic disassembler
that can chase down 'references', and can translate local/parameter
references into symbols if the header for the function hasn't been
"stripped".
Currently, my byte-code stuff hasn't been translated to C. Its still in
the original Draco from my AmigaMUD system. I don't expect that work
to be hard - probably a day or two.
I'm not sure I've answered your question here.
Note that my system's "object model" is entirely within the database -
the language itself has no specific object-oriented things in it, and
so none are seen in the byte-code. Perhaps I should briefly go through
that model so folks will know what I'm talking about. Those familiar
with it can skip this. I've posted small pieces of my MUD language
code before, but consider this example:
Me()@hits := Me()@hits + 1;
'Me' is a builtin function that returns a reference to the database
record for the active character (PC or NPC). That reference is of
type 'thing' (yes, that's the official type name!). 'hits' is here
assumed to be another database reference, this one of type 'property int'.
A 'thing' is stored in the DB as a small fixed structure (includes a
reference to any single parent) and a varying size array of property-
value pairs. Thus, if a 'thing' in the database has a property 'hits',
then that array will contain 'hits' as the property reference, and some
integer number as the value. This array is flexible, in that property-value
pairs can be added and removed at any time. So, the above code, running
on my byte-code machine, does:
- run builtin 'Me', save value on stack
- push reference to property 'hits'
- run builtin 'Me', save value on stack
- push reference to property 'hits'
- execute 'getproperty' code
This will call on the database routines, which will retrieve the
'thing' referenced by 'Me' (might need reading from disk), and
then search for the 'hits' property in the property-value list
of that thing. If the property is not found, the parent pointer
of the thing is followed, and this is repeated until a value
for 'hits' is found. This is my inheritance. If no value is
found, a default value (0 for ints) is returned. The returned
value is pushed on the stack in place of the two arguments.
- push constant 1
- execute add: pop two ints, push the sum
- execute 'putproperty' code
This is another database call. The top 3 stack elements identify
the 'thing' to put the property to, the property to put, and the
value for that property. If the property already exists in the
thing, then its value is updated. If not, it is added to the
array of property-value pairs. Note that this will break any
inheriting of the property from ancestors. Such properties can
also be deleted at will, thus re-inheriting from ancestors.
I think it comes to 24 bytes of byte-code.
So, my object model is quite different from, say, C++'s or Java's. It
is more expensive at run-time, but is completely run-time flexible,
and saves huge amounts of space, by inheriting *values* rather than
*structure*.
>Discussion for what we want in a VM is called for. Discussion of how a
>VM module should interact with the rest of DevMUD is even more important.
Definitely.
As seen, my VM doesn't have much in it - its mostly done by builtin
calls and database calls. This works for me, but more VM support will
likely be needed for other object models. How much will depend on
what that object model is like. If the support is all done with calls
to native-code functions, then its trivial to add. If we end up like
C++/Java, then byte-codes with constant offsets to the required fields
are also trivial. If we want their style of virtual functions, then
we likely need a byte-code which takes an object reference, and some
kind of identification of the required function, and does the call.
That identification might be an inheritance level and an offset. If
we want to do run-time lookup based on names, then all offsets get
replaced by references to string constants (which can be done in-line
in the byte-code).
- does the VM definition include function headers?
- does the VM definition include the object model?
- does the VM definition specify all builtin functions?
- what datatypes does the VM support?
- how much checking of byte-code does the VM do before it tries
to execute it? (mine does none)
- how much checking is done as byte-code is executed (e.g. things
like stack overflow, divide-by-zero, invalid references, etc.)
To start some discussion, here is a list of external references from
my byte-code engine to other parts of the system:
- memory allocation/free (for stacks)
- lookup of function header by PC value (for tracebacks)
- output to the active client, if any (for tracebacks, errors)
- lookup of references (for tracebacks)
- lookup of builtin functions by reference
- checks for run-time exceeded
- references to active agent status for security issues
- reference to other interpreter entry point for non-byte-code calls
- reference to a system abort routine for conchecks
- lookup of functions by reference, for calls
- references to various utility routines, like string operations,
'fixed-point' arithmetic, etc.
- references to the dozen or so database routines
The file exports only one function - the top-level entry point to do
byte-code execution of a given function. The state in the file (my
system isn't multi-threaded, so they are just static variables) consists
of a pointer to the current function, pointers to the top and bottom of
the byte-code stack, and the SP, FP and PC byte-code registers.
Whew! Sorry for the length, but I hope this gives folks something
solid that we can talk about, in terms of what a VM is all about.
--
Don't design inefficiency in - it'll happen in the implementation. - me
Chris Gray cg@ami-cg.GraySage.Edmonton.AB.CA
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Chris Gray
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Hal Black
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Jon Leonard
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- Flamebite of the day Vadim Tkachenko
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- META: DevMUD, MUD-Dev, and (list) futures Jon Leonard
- META: DevMUD, MUD-Dev, and (list) futures James Wilson
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- DevMud RFC #1 - Was DevMUD considerations and the Halloween article James Wilson
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Niklas Elmqvist
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Thandor
- My vision for DevMUD Robert Woods
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Thandor
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Adam J. Thornton
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Adam J. Thornton
- My vision for DevMUD Caliban Tiresias Darklock
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD James Wilson
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD James Wilson
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Darrin Hyrup
- My vision for DevMUD Jon Leonard
- My vision for DevMUD J C Lawrence
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Hal Black
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Chris Gray
- My vision for DevMUD Chris Gray
- My vision for DevMUD Ben Greear
- My vision for DevMUD Jo Dillon
- My vision for DevMUD Ben Greear
- DevMUD Prototyping (was META: DevMUD, MUD-Dev, and (list) futures) Jon Leonard
- DevCore Project Management Ola Fosheim Grøstad
- DevCore Project Management Adam Wiggins
- DevCore Project Management Ola Fosheim Grøstad
- DevCore Project Management Simon Duggan
- DevCore Project Management Jon Leonard
- DevCore Project Management Chris Gray
- DevCore Project Management Darrin Hyrup
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Chris Gray
- Drama Theory Ling
- Moral license (My vision for DevMUD) Ola Fosheim Grøstad
- Moral license (My vision for DevMUD) ApplePiMan@aol.com
- Moral license (My vision for DevMUD) Ola Fosheim Grøstad
- Fwd: My vision for DevMUD Jon Leonard
- DevMUD Prototyping Niklas Elmqvist
- Altima... Thandor
- Fwd: My vision for DevMUD Darrin Hyrup
- Tim O'Reilly's "Open Letter to Microsoft" ApplePiMan@aol.com
- Tim O'Reilly's "Open Letter to Microsoft" Adam Wiggins
- [DevMud] quick question... Franklyn Colebrooke, Jr.
- signal to noise... Andrew Wilson
- "knights and merchants" - NYTimes review James Wilson
- ADMIN: DevMUD posting authority promotions J C Lawrence
- A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
- A Small Conceptual Object System For MUDs Emil Eifrem
- A Small Conceptual Object System For MUDs Mark Gritter
- A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
- A Small Conceptual Object System For MUDs Jon A. Lambert
- Random Quest Generation chris@realm.zfn.uni-bremen.de
- Random Quest Generation Chris Gray
- Random Quest Generation Michael.Willey@abnamro.com
- Random Quest Generation J C Lawrence
- Random Quest Generation J C Lawrence
- Quick socket question Dr. Cat
- Quick socket question Jon Leonard
- Quick socket question Ben Greear
- Quick socket question Chris Gray
- Quick socket question J C Lawrence
- Quick socket question J C Lawrence
- Quick socket question Adam Wiggins
- Quick socket question Petri Virkkula
- ScryMUD [CUSTOM] Released under GNU General Public License Ben Greear
- Quick socket answer Dr. Cat
- Rebol Ling
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Chris Gray
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... JavaAl@aol.com
- Spell components, chemistry, and the like... Adam Wiggins
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Hal Black
- Spell components, chemistry, and the like... Ling
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... Ben Greear
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Hal Black
- Spell components, chemistry, and the like... Peck, Matthew x96724c1
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... Ben Greear
- Spell components, chemistry, and the like... JavaAl@aol.com
- Spell components, chemistry, and the like... Chris Gray
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... Adam J. Thornton
- Spell components, chemistry, and the like... Franklyn Colebrooke, Jr.
- Spell components, chemistry, and the like... Emil Eifrem
- Spell components, chemistry, and the like... Nathan F Yospe
- ADMIN: Attributions J C Lawrence
- AMIN: Unsubscriptions J C Lawrence
- OO Design Question Brad Leach
- OO Design Question J C Lawrence
- Chemistry [Warning, scientific content] Peck, Matthew x96724c1
- MUD clients, testing Chris Gray
- MUD clients, testing Scatter
- MUD clients, testing J C Lawrence
- JOB: Project manager and scaling/networking guru needed for game project J C Lawrence
- More module ideas Mark Gritter
- The Innerworld Project Niklas Elmqvist
- META: FAQ's bios. Ling
- Mage 2 Mage 0.89 J C Lawrence
- Game library notes J C Lawrence
- World Building Page Ling
- ScryMUD [CUSTOM] Code release 1.8.1 Ben Greear
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Ling
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Ling
- DIS: Client-Server vs Peer-to-Peer Nathan F Yospe
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
- DIS: Client-Server vs Peer-to-Peer Mik Clarke
- DIS: Client-Server vs Peer-to-Peer Adam Wiggins
- DIS: Client-Server vs Peer-to-Peer Jon Leonard
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- Ruminations on CVS and developing in the Bazaar Ben Greear
- Ruminations on CVS and developing in the Bazaar Chris Gray
- Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
- Ruminations on CVS and developing in the Bazaar J C Lawrence
- Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
- Ruminations on CVS and developing in the Bazaar J C Lawrence
- Ruminations on CVS and developing in the Bazaar Petri Virkkula
- DevMUD: List data, subscription, and the rest J C Lawrence
- DevMUD: List data, subscription, and the rest J C Lawrence
- Atention SSH/Java-developers (MindTerm update) J C Lawrence
- ScryMUD/Hegemon code Release Ben Greear