Steps

[Matthew Tuck]

Hans-Dieter Dreier wrote:

> 1 Write a memory manager (shorthand: MM).
> ...

A couple of things that you don't mention - we need to write a
cross-platform widget capability before the intelligent editor.  We may
be able to use the Mozilla XPToolkit - I'm not sure about what
license-compatibility issues there would be.

Also, bootstrapping is not mentioned.

> the person programming this should have very good C++ knowledge
> (which unfortunately is not the case for me)
> to provide the necessary "smart pointer" stuff
> and keep the interface as open as possible,
> so people don't have to rewrite it all
> when trying a different MM implementation.

Well that's why you can have a designer and a coder.

>  // the handle of the object at the next lower memory location
>  MMBlockHandle mpPrev;

I'm not sure why you'd want to do this here - since we're talking about
a VM over an existing memory space, it's really just a collection of
blocks.  The way we want to access that memory may not become apparent
until later - and the access specification to use would then become
apparent.

Or am I misinterpreting what you're referring to here, and you want to
allocate large chunks of memory at one time and use C's pointer tricks
to allocate objects in there?

> BTW, I started to write such a thing several years ago (in C, not C++),
> but at some point I got into trouble with the implementation
> (automatic type conversions if I recall right).
> It had MM, VM, object loader and a simple parser.
> My source backup has been damaged, so I don't know whether
> it would be worth trying to revive this thing and port it to C++.

Are you familiar with the different memory allocation systems like
bit-map, hole list and buddy?   If so, which would you say you did?

> Object loader:
> It should accept a text format and produce memory objects.

Why text?

> It should have a simple, single-namespace symbol table
> to provide symbolic references to other objects.
> It should be able to process these data types:
> - References (to other objects that are already known)
> - Integers
> - Strings
> - NULL (to provide NULL pointers)
> - Maybe some other constants that are used to represent special object
> handles

You should probably include characters and arrays instead of strings. 
In fact I don't think the object loader or memory manager would need to
be concerned with integers and characters at all.

> Example how a piece of "Ultra assembler" might look like:
> ...

What you propose seems to be a sort of persistent dump description
language.  I'm not too sure how this is used at startup.  Why exactly do
you want to load a set of objects.  I'm assuming we're not talking about
loading any code here, e.g. class objects, but just state.  So why would
persistence be better than object creation code?

> VM:
> This should be a simple stack machine with just a few "instructions".

Why stack machine?  I believe we've talked before about distributing
programs as ASTs - they seem to have benefits - therefore it would
involve a runtime conversion.  For a native implementation, this would
be OK, but a conversion and then an intepretation would have to be
inefficient.

> NULL: Execute the object on top of the stack

What do you mean by execute object here?

> Parser skeleton:

I'll have to take a look at this shortly.

> Refine parser skeleton, write Runtime Library:
> This certainly is the main effort, and it never ends.

Well in the traditional sense, the parser should end with syntax
independence.  =)

> IMHO most important is that the memory structures used
> are designed properly before mich effort is invested here.

> Parser Table Generator:

If we go with intelligent editors then it's probably not worthwhile
looking at these unless we do it first.  They are probably not going to
fit well with the new editing paradigm.  A different sort of generator
will be needed, and it's not worthwhile writing one that will be
discarded.

> Intelligent Editor:

> A *text* editor has little need for graphics, after all
> (apart from color, bold, underline).

It's an interesting point, but one of the main aims of an intelligent
editor is to use GUIs in new ways rather than pretend we're still in the
text file world - which - let's face it - is as old as punched cards. 
It could still be a stepping stone of course, although it might not be
easy to move code just like that.

> Debugger:
> Should be tightly coupled with editor.
> Need not include hardware level.
> Needs some support by VM
> (a "debug VM" as opposed to a "release VM" ?).

A debugger is essentially an interpreter with a front-end.  It shouldn't
be difficult to define the code with two different modes.  Allowing the
editor to run code would be useful whether debugging or not.
 
> Persistent storage:
> To be able to persistently store the current state
> of the machine not only speeds startup time
> but also may aid debugging (Core Dump).

An interesting idea would be a dump-and-exit statement, where a program
quits.   When you restore it it resumes at the next statement.  Whether
this would be useful is another question.

VMs, debuggers, profilers, etc. are all similar.  Hopefully, they will
be able to be one program or DLL, or at least the same codebase.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
             mailto:matty@box.net.au (ICQ #8125618)
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/