Hardware references.

[John Morrison]

Hi Ray,

Ray Dillinger wrote:
> 
> On Thu, 8 Oct 1998, John Morrison wrote:
> 
> >to help jumpstart the stalled JOS effort.  I have assembled a (mostly
> >C++ with a smattering of assembly) free cross-development toolchain and
> >used it to successfully build and download a native-code runtime which
> >does the obvious things (e.g., puts the [expletive deleted] Intel part
> >in flat 32-bit protected mode, probes memory, catches interrupts, etc.),
> 
> I would actually be very interested in seeing whatever
> references you used to figure out how to do that trick.  It
> seems like all the assembly-language stuff I can find is
> preoccupied with how to interact with existing operating
> systems, and precious little has any real information about how
> to interact with the bare hardware itself.

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.  With any luck, I'll be releasing the source later
this weekend (the distribution will include all the non-standard Linux
tools required).  If enough people care, I'll post the announcement here
as well as to the JOS-* mailing lists.

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.  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.  With respect to the hardware,
I'm used to dealing with this sort of thing on Motorola and other parts,
but the Intel/PC architecture is, well, to put it kindly, challenging.

> I'm elbows-deep in my compiler project, and I want to be able to
> spit out kernel-mode executables and drivers from it... which
> involves interacting with bare hardware.

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've already figured out that I will have to use a completely
> different file format for DLL's (including device drivers)...
> a dynamic typing system involves a completely different set of
> assumptions than those embodied in existing DLL formats.

Well, ummm, an OS capable of DLLs/DSOs presupposes a level of complexity
(maturity?) that I am currently unprepared to implement (which is why
the JOS variant I'm working on is not currently envisioned to provide
JNI support any time soon).

-jm

-- 
==== John Morrison ==== jm@mak.com == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA
02138
==== vox:617-876-8085 x115
==== fax:617-876-9208