Project: Some aid for low level programmer

[Peter Wiehe]

> The concept I have in mind is some framework to dump low-level code,
> and build functionality up from there.
> 
> If it's written in a declarative way in LISP, the same framework
> can be used indifferently (through proper macros) to produce code
> at compile-time, at runtime, etc. ...
> ...
> The kind of functionality I envision is at first a basic runtime
> system,
That would apply very exactly to the approach I thought of.
Some pseudo code (won'T look exactly like this!) of my idea:
main{
	if(cpuType == "XT")
	{
		printf("No XT support");
		exit(-1);
	}
	getDiskLabel(...);
	if(registerSize < 8 | registerSize > 64)
	{
		printf("Can't handle this sort of CPU");
		exit(-1);
	}
}
or (if (= cputyp "XT") etc
(When I'm worked into Lisp again, I will do it more correctly.)

> ...Also, with proper declarative style,
> we can start with have simple strategies to produce bad code
fast, 
> and define more elaborate strategies as we evolve into
sophistication.
> 

> but the ability to control the emitted code can then be used
Here's a definitetively NO and YES for my plan.
No for compiler-like optimizations (optimazation levels etc.)
Yes when it comes to the fact, that there is something under
the highest interface layer that can be changed via the source code.
example: 
if(cpuType = "Bla123")
{
	registerSize = 16; /* You see? Writing to sys specification!*/
}

> Things like GC, persistence, logging, debugging, trapping exceptional
> behaviour, enforcing security, etc., can all be done by instrumenting
> the code being generated at the right level of virtual machine.
In my system you have to write that in the code of the language or with
the expressions you get with the extensions.
So if you use Lisp which has buildin self modification, you can self
modify the virtual machine. If you don't hav a proper language or don't
write such stuff it' not there.
And for VMs: My system is in no way virtual.
As I my original intention when I came up with this concept was to write
a lisp OS I think I understand parts of your OS approach.
But my system is more like the CLib except that it is not a lib and
is on Asm similar stuff (hardware)
 
> At first, we start from a runtime assembler,
You could write a runtime assembler with my system,
at your choise system indepent like Lightning or system specific.

> that has a first-class representation of code being emitted,
Typical intermediate code like known from compilers and interpreters?
> including processor mode and linking information
Is this
a) On top of an OS, steps of compilation
or b) in a bootloader/kernel creating code at boot time?

> More elaborate macros, that might require more contextual information
This is ALL in my extensions. This means you have that kind of system
specification stuff at hand that you normally only think theoretically
of. Like CPU type, register size, which kind endian, infos about the
hard disk, bit access,etc

> into more and more elaborate virtual assembler.
If I understand more of the concept I probably have to come back to this
topic.

> This is the approach used by lightning, and not unlike the CMUCL VOP.
Don't know CMU CL (yet!! may change).
I don't know which lighning technique you mean in particular.

> Over this runtime assembler (or collection of assemblers, for each
processor), 
> we can build a straightforward code generator for some
> high-level language,
I would take a compiler or interpreter and create a language binding.
If you for example would use Common Lisp it would be supported.
ANSI C, Scheme, further Lisp dialects are on my list, too.
(I'm thinking of a purely functional Lisp dialect. Let's see if that is
too much for me).
It is now up to the compiler/interpreter what comes out at the end.
You see, code generator stuff is completely ignored by my approach.

> by mapping semantic constructs directly into suitable macro instructions.
That sounds like the inner core, the "engine" of my system.
But the definitions in this "engine"
- are defined by a system specification description file
- can by read from and written to by the source code in a cooperation
   with the compiler/interpreter. Most programmers will take the spec.s
   statically and not write to(=change) them.
You could write a driver or a bootloader with it, for example.
If the programmer doesnt change the specs and only use the uppermost
expressions like disk or some CPU register operations (MOV, XOR etc),
the whole thing looks pretty simple (hiding the logic engine underneath).

> This way, we can hopefully achieve code that runs at acceptable speed 
My system would not be optimized at all. Again: If you have a powerfull
compiler you get fast code. If you use GCC, you get GCC optimization.

> not so high-level language that we bootstrap (not so high-level: 
> although control structures are high-level, basic types might be lacking 
If you Lisp or another language that easily puts itself into produced
bytecode, you can take the mini core of the lisp interpreter with you
into the bootloader. You can take the constructs of my system (they
include loops etc!!) with you into the bootloader, but onyl statically.
Then you can't modify them anymore. But if you use the lisp power
cleverly you can modify some of them in the nootloader!
I will write a C language binding, too (as I mentioned). The C
programmers would not be able to program such code.
that is the part where my system depends langauge-dependent because
it is completeyl passive to the langauge's builitn policies and
techniques.

> From then on, we can start doing more elaborate things:
> do analyzes to select simpler VOPs and remove unnecessary checks.
In bootloader/kernel? not good, do that only at compile time IMO.

> to runtime analyzes and code production; from a simple virtual machine 
> definition that dumps an interpreter for the virtual machine to a compiler 
> that rewrites the high-level instructions into virtual machine instructions 
That is outside of my system (but I guess you got the idea by now)

> So the whole idea is to have a high-level framework for dumping low-level code
> and build compilers for high-level code in a declarative way over it.
What do you mean by "in a declarative way" and "over it"?

Did I get that right: A parsergenerator which build a parsergenrator?

Regards Peter Wiehe