Work / Virtual Machine / Dev Blog

2011-02-20 01:01:52


I have been thinking about program isolation and interfaces recently and am thinking of making some changes to how things are imported, exported and made public to the rest of the vm program.

At the moment, an identifier must be exported by a translation unit for other translation units in the same program to use it. Implicit in this fact is that there is no way of exposing an identifier internally in a program that is private between translation units (i.e. the host has no notion of it). While this may be desireable behaviour (in terms of openess at least), i beleive this is an inconvenience to the efficiency of the host <-> program interface (i.e. identifiers are exported to the host that the host will never have to use).

Another (more syntactic) issue I have is the necessity to explicitly declare imported identifiers -  i really don't know why i did it this way looking at it now - i want to change it so that identifiers are autmoatically imported. I beleive this is possible (probably through hindsight now which might be why i did it like this originally?) because the list of instructions whose operands can be imported (external) identifiers is finite and contents known. So the parser would just pick up the external identifiers as it parses the operands, rather than looking for explicit import declarations.

Of course, this means there can be no explicit imported identifier checking in the compiler - all imported identifier validation is moved into the execution core program load module (as thats the only part of the system which can validate imported identifiers against the actual available list of importable identifiers). I hope that makes sense.. :p

Thus i propose the following ammendments:

  • Create new directive 'public' to enable sharing of identifiers between translation units
  • Convert import & extern directives to optional components (redundant, technically)