Just as I was finishing this email I realized that if we "steal"
code from GCC or GAS like I am suggesting we become
bound by the GPL, which has been determined to be an
unsuitable license for us to use.
The ideas are good, but in order to get around the GPL we
would either need to adopt it, or reinvent the GNU Assembler
project. I'm in favor of finding a suitable replacement
project that:
- Does not contain the license problems the GPL represents
- Is designed to be platform independent
- Has implementations for several processors already
- Preferably supports object orientation
(GAS does not, the C++ compiler does, so maybe we
could use a C++ interpreter)
Alain Farmer wrote:
> Micheal: Because we'd be using the gcc bytecodes our
> stacks could be natively compiled on that platform
> with no interpreter needed.
>
> Alain: Wow! Are you pulling our leg? You are putting
> us on, right?
Not if I understood my compilers class.
There are a number of compiler details that I may be getting
confused here but here's my understanding of it.
All a compiler does is translate one language into another
language. Usually the second language is the assembly language
for a particular processor. In the middle the compiler needs
to describe the program to be executed. The collection of
data structures used to do this is known as the compiler's
"Internal Representation".
GNU invented an assembly language for themselves.
GNU Assembly has been engineered to be processor independent.
The GNU Assembler needs to have an internal representation to
describe the program to be executed before it can write
the processor specific object code.
This internal representation needs to be processor independent to
completely describe the GNU Assembly language.
That internal representation could be used for anything that needed
to describe a program to be executed.
OpenKard needs to describe a program to be executed. We call those
programs scripts.
That said here's what I envision:
Programmer writes a script and executes
"Set the script of someobject to someopentalkscript"
The interpreter then translates the script into the internal
representation. If for some reason it can't do this it fails
to set the script of the object and throws an exception. If
successful it then stores this new binary script in the script
property. So if you were to look at the binary data of the
script property it would be the compiler's internal representation
for that script. The text of the script would need to be stored
in a separate location for re-editing. (The specifics are debatable)
So here's where the magic happens, most stacks are static when
they go to the customer. Except for the "do" statements they will
not change once you have created a standalone. If we are using
the same internal representation for our binary scripts as the GAS
compiler then there is nothing saying that we couldn't take the object
code generating parts of the GAS compiler and use them to compile
the binary scripts even further into processor specific object code.
I believe this would be a completely novel approach to interpreters
as it approaches something more like a real time compiler.
-- Michael --
