Compiler & VM (was: Steps)

[Hans-Dieter Dreier]

Matthew Tuck schrieb:

> Hans-Dieter.Dreier@materna.de wrote:
>
> >> Yes, the tree would operate in a similar sort of way, with code for the
> >> node put in the node itself.
> > You mean that you would include information on how to generate code
> > within the definition of each node, right? If so, there's a little
> > problem: Code generation may depend on the compiler as well as on the
> > node. Different cimpliers may produce different code. You got a
> > 2-dimensional array of code generator infos.
>
> Compiler?  I thought we were talking about the interpreter?

For the moment there will just be a compiler, that's true.
But that too needs a parser which has to interpret those nodes.
Eventually there will be different parsers,
regardless of whether they will be used with an interpreter or compiler.
I was just trying to address future needs.

> > - GC. Objects for intermediate results need to be reachable or they might get
> > collected. That would not be good... GC would have to examine the C stack
> > otherwise. But the C stack isn't GC friendly. It would involve a lot of
> > extra work.
>
> Well there are C collectors out there that do this ...  But an explicit
> stack straight away is probably the best thing to do, at least to handle
> exceptions.

It certainly is possible to interpret the C stack from a GC,but I would not want to do this
if I can help it:

1. Its a special treatment, quite different from examination of our objects
2. It involves guessing whether something might be a pointer or not.
We got to be careful when following these pointers in spe - all that stuff
that is messy about C GCs comes in through the back door.
3. We might introduce another dependency on a third party product
(the C compiler that is used) if we mess around with their stack.

> >> The compiler can probablly have a fairly minimal syntax at first too.
> > Certainly it will have to. But that still will be a lot larger than a simple assembler.
>
> Yes but wouldn't the compiler be easier to use to generate test cases
> for the VM?

I don't think so. On the contrary - assemblers generally are better at producingarbitrary
structures because the programmer specifies it all.

> >> Then it can be expanded later.  Essentially the same as what your
> >> assembler is, except existing work can be built upon.
> > Most of the assembler's ingredients can be reused if we keep that in mind.
>
> Like what?

Token recognition (numbers, strings, names)Symbol table handling (flat namespace though, but
for a start that'll do)
I/O handling

IMO most ingredients should be packed into MCs,
so they may form a rudimentary runtime system.

> >> Even if you wanted to parameterise by table, how are you going to change
> >> the table.  Since direct parse table manipulation is difficult, you'd
> >> want to set up a parser table generator anyway.  It'd be quicker than a
> >> normal compiler, but we'd have to spend time writing it.
> > We'd write a parser table generator in due time (rather sooner than
> > later). That's a bit effort, right, but it keeps us flexible and
> > independent from the C compile chain. I see manual table entry
> > only in the beginning.
>
> I've never tried that, but I'd think it would be next to impossible.  By
> the same logic I would use a manual parser until the table generator was
> ready.

"it would be next to impossible": it = manual entry?If you mean that, I can assure you that
it is not that difficult.
Not if the syntax is simple. I wouldn't want to do it for C++ though...

If you mean converting a syntax (say, annotated BNF) to a table,
that doesn't look frightening to me although I've no algorithm ready for that.

> > Would you please explain what you mean by "parser framework"?
>
> Beats me.  I was referring to actually linking subclasses into a parser
> framework (abstract class), but when I think about it, I have no idea
> how that might work.  All I can think of is a table parser.  So forget
> that.  =)

BTW: If we use C++ (I'm not entirely convinced that it is so much better than Cfor our
purposes) please keep in mind that C++ vtables would not mix well
with my object layout proposal - either we'd have to abandon or heavily redesign that
or refrain from using virtual C++ methods and RTTI for all Ultra objects.

> > We need to do most of that for a hardcoded one as well or
> > it will remain an isolated affair, not integrated into the
> > rest of the environment, and we will need to ship a C
> > compiler and yacc or whatever it takes along with our code.
>
> Well yacc generates that parser in C, then the code is linked in with
> the rest of the C, so you wouldn't have to do this.

If you don't mind a recompile each time your syntax changes...Well, I already said a lot
about test cycles.

> > In the impl, it looks like this if it's not inherited from the interface:
> > ...
>
> I really don't want to require any new language features here, which
> this might entail.  It can be done via inheritance (and this allows more
> than one use of the code).

It's no new language feature, it's just a different treatment by the editor.The read-only
parts are not present in the AST (at least not in the derived impl,
this would be redundancy and make no sense).
They were taken from the type defintion and shown here mainly for the user's
information.

> The other option I can think of is using detached elements.  These can
> have different access control, so the main element would be locked down,
> and the detached elements would be free to be accessible.  In a view
> where the detached elements are added, this might appear as you describe
> here, with only detached elements accessible.
>
> This made me wonder whether detached elements could be eliminated since
> they have much of the same utility as inheritance.  At least one
> difference is that detached elements get to access private members of
> surrounding objects.  If we make a member C-style "protected" then not
> only can it be access by subimpl, but also by subsubimpls and so on.

As far as I can see detached elements and the template-like deviceI showed are different
things.
They may serve the same purpose but have different characteristics.

> --
>      Matthew Tuck - Software Developer & All-Round Nice Guy

--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)