Hardware references.

[Ray Dillinger]

On Thu, 8 Oct 1998, John Morrison wrote:

>
>Well, actually, if I were you, I'd just prepend the nasty grotty
>hardware code I wrote (or equivalent) to the front (chronologically and
>spatially speaking) of your code as a sort of "crt0" (please excuse the
>UNIX-speak) prologue.  

As an assembly-language "prefix" that the compiler must emit
whenever it's outputting a bootable kernel image?  If it's 
suitable for that, then yes, that would be a wonderful thing.

>If you want to do it yourself (perhaps you have a latent masochistic
>streak that needs indulging :=), I would be only too happy to provide a
>few references that I have personally found helpful.  

Please do. <Thwack!!> "Thank you sir, may I have another?"

>However, please be
>advised that there are a lot of issues to cover (the Intel architecture,
>the PC architecture, the BIOS boostrap behavior, your toolchain
>executable formats such as ELF, a.out, and raw binary, etc.).  Trust me
>when I tell you it's a mess -- building the toolchain was every bit as
>nasty as getting the hardware to behave.  

When you use the word "toolchain" do you mean the Editor/
Compiler /Linker /Loader /Assembler /Disassembler /Debugger
combination that is needed for system-level development?  That's
where I've started work, and it looks like a fairly big job.  I
had hoped that, when the major work on the tools was nearer
completion, getting the hardware with no OS to behave the way 
my VM does (and retargeting my compiler at actual bare wires
hardware) would be more a matter of discovering a few hidden
mysteries than a conquering of a thousand nit-picking details -
I haven't really been there yet, though, so if you say it's
really grotty I believe you.

Right now I have a Virtual machine which runs in any r4rs/r5rs
compliant scheme. It slowly runs an extremely bulky, low-level
simulated machine code called FACE.  FACE is not designed to be
an efficient "bytecode", but is designed to be sufficiently
low-level that machine code style optimizations can be done
directly on it, and, like RTL, the optimized code is then
ridiculously easy to translate into particular types of Actual
machine code.  (I picked FACE isntead of RTL because FACE is a
semantic-retention code -- dynamic type information and other
optimization information is more available in later stages of
compilation than with RTL).  I plan to build an assembler,
debugger, linker, and global optimization utilities around this
VM, but right now those are secondary goals to finishing the
scheme - to - FACE compiler.

>If you're going to do native-code, I understand.  If you're going to
>compile to a bytecode, then you could potentially save yourself a
>certain amount of work.

I am absolutely going native-code.  Bytecode doesn't perform 
as well.  LISPs in general suffer from a reputation of having
inferior performance. The reputation is no longer as deserved as
it once was, but political realities being what they are, unless
the OS and applications can be observably **FASTER** than
Windows (an easy target, but still) we will have to cope with
those prejudices.  So -- no shortcuts.  

And more importantly, why bother doing it at all if we don't do
the best we can do?  If you've ever had a programming job where
features and schedule were more important than quality and
correctness, you've had to swallow a lot of bile and take a lot
of shortcuts (including more than a few which were simply "The 
Wrong Thing To Do", like Visual Basic <shudder>). Recreational
projects like this represent a chance to do things *right* for
once; we are under no schedule constraints and free to implement
things as we believe they ought to be implemented.  And for me,
at this stage, that means compiling to raw machine code.  It
means handling dynamic libraries and time-sharing and security
and all the other awful details of a "real" operating system,
eventually.

It's not a masochistic streak, I don't think.  Doing things
*right* actually feels very good.

				Ray