[LispM-Hackers] More bare iron progress

John Morrison jm@mak.com
Fri Mar 8 17:34:01 2002


Hi;

"James A. Crippen" wrote:
> Whee...  Can you print hex or octal?  Can you print at all?

I have a stupid "kprintf" that behaves more or less like you'd expect it
to, except it is hell-bent on using only hex radix output for numbers. 
This should be easy to change to octal, anyways, and that would pretty
much enforce our octal-only convention.  Every damned number goes out
through that one routine (and, Boy, is it UGLY -- if I had a dog that
looked like that... I'm sure you know the rest).  Hell, I don't even
have streams (although I expect they'd be easy to whip up for most
stuff).

> > (2) I'm sure many other things don't work.
> 
> Oh yeah, you don't have an OS.  You'll be in for lots of
> implementation...

Funny how that works.  It's like being on a desert island, and you
forgot your Swiss Army Knife.  Shades of "Castaway."

> > (1) Whether interrupts still work.
> 
> Why not?

Because:

(1) I'm a lazy bastard, and I haven't checked, and I'd have to

(2) Change the program logic, which basically gives up and halts after
booting up because it (for some Godforsaken reason) thinks it doesn't
have an FPU.  It DOES have an FPU.  I KNOW it has an FPU.  I haven't had
time to run this to ground, although I *have* had enough time to think
up some new acronym expansions for "FPU."  I could put it in an
idle-loop, make sure the interrupt debugging is on, and bang on the
keyboard and see what happens.  That won't take long.  Might do that
later tonight.

> > (1) Now would be a good time to let me know whether the inheritance
> > scheme is acceptable.  If so, I can start making changes to the code
> > to make it more compatible with e3 (e.g., change all my "jju32" types
> > to "e3u32" etc.)  I will have to make at least one CVS directory, etc.
> 
> Go for it.  I can't find anything wrong with the idea so far.  But
> before you change anything take a moment to outline how you think it
> will work here on the list.  We'll all poke holes in it and give your
> ideas some constructive criticism before anything is cast in stone.

OK.

> > (a) Rip out the BOOTP stuff, because almost nobody uses it anymore (I
> > couldn't even FIND one that would build on my RedHat 7.2 box).
> 
> I thought the ISC dhcpd could support BOOTP with the appropriate
> compile time incantations?  I haven't built it for six months so I
> don't remember...

Good point.  I'll look.  I just did the "./configure && make" so I
didn't look really hard.

> > (b) Leave it, and add the DHCP stuff as a compile-time switch.
> 
> Leave it in and do this for now.

Sure.

> > (c) Try to make the ersatz ucode REALLY clever.  ("Was I Etherbooted?
> > If so, was DHCP or BOOTP used?  If not, was I GRUB-booted?  How do I
> > find the load band?")
> 
> If you take option (a) above this can be implemented later.
> 
> > (d) Try to make it not care how it was booted to the maximum extent
> > possible.
> 
> Uhh, this would be good too, n'est-ce pas?
> 
> In short, both (b) and (d) and later maybe (c).

Well, I guess I didn't write them as "mutually exclusively" as I thought
I did, eh?

-jm

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