>(note: I looked back over this mail after composing it and I want to
> warn people who are not familiar with me yet that I am very
> sarcastic and am full of ridicule even when discussing
> important topics. Please don't take it that I lack tact
> or am not being serious, because that simply isn't the case.)
Feel free to express yourself, my english (colloquial and otherwsie)
is bad anyway, and I guess the others don't care :-)
>Here is what I need:
> The following utilities I need for development.
> 1) CVS/RCS, latest on prep.ai.mit.edu is fine
RCS comes default with IRIX today. But I know it is not
the latest. OK, and I'll add cvs.
> 2) Emacs-19.31 (rms should release within 2 weeks)
> 3) All GNU smidgen-type utilies as the default binaries
> (this include fileutils/sh-utils/sharutils/diffutils/
> Actually, Let me just stop short and say, if there is a
> source tarball for it on prep.ai.mit.edu:/pub/gnu I would
> like the latest installed on the machine I develop on.
Many of these are in our freeware project. Ready to install with
the click of a mouse. (Yes, one of the cool things about SGI is
a joe-user software installer infinitely better than RPM/glint.)
(yon) 84 /var/tmp> which find
(yon) 85 /var/tmp> which tar
(yon) 86 /var/tmp> which grep
(yon) 87 /var/tmp> which chmod
I'll add the missing ones. That's easy.
BTW, we called it '/usr/freeware' rather than '/usr/gnu' because
many packages are from other sources and because some of our
customers asked us to stay away from their /usr/local.
> 4) xfishtank (don't laugh)
Bingo. Larry runs this too. You weird people. Is this a conspiracy? :-)
> 5) fvwm
> 6) teco (Must support full teco command set as described
> in original DEC manuals! TECO is _the_ renaissance editor!)
I'll try to build these too.
> The following would be nice, but if it will give people
> bladder problems to do these then don't go out of your
> 1) MIPS 400 manual is some online format (not postscript,
> something I can cut and paste out of an emacs buffer etc.
> so maybe info or pure ascii text would be fine, I could
> care less about the formatting, I just want the words
For MIPS ABI stuff: try the following web site,
Tell us what's missing there.
As for the MIPS programmer's Assembly manual. There is an excellent one
internally on the Web... I'll try to get you a copy soon.
> 2) Docs on the ethernet/scsi interfaces and I/O bus
> architecture for the first machine I will be getting
> this to work on, again text/info format would be nice.
> Of course I will probably just stuff in the ready
> drivers you might be getting to me into Linux but I want
> to write my own from scratch in the near future after
> 3) I know as much as a bum on the street about SGI machines
> and the various lines, a nice "roadmap to sgi workstations
> and servers, plus the hardware gook thats inside" type
> thing would be very useful to me.
I'll leave these to some other folks on the list.
> I will feel more comfortable if:
> 1) I became very familiar with who the heavy low level MIPS
> assembly level hackers are who I will be dealing with while
> I am there. Please tell me who they are, introduce, make
> us say hello to each other, you get the idea.
I believe the most knowledgable low-level gurus on the list are
Bill Earl and Jim Barton, I'm sure there are more, I just don't
know everyone on the list personally ...
> 2) I know the policy on loud music in the office I'll be in
I'm trying to get you an office right by mine :-)
>I've thought it over and to me the best plan for things this summer to
> a) R4400 32-bit "proof of concept, yeah we can pull it off"
> port happens first, side effect is that I become intimate
> enough with the chip that I can do things more efficiently.
> b) From here we look into the 64-bit stuff and whether that is
> is even desirable on 64-bit. (this would be my first
> 64-bit port outside of my initial UltraSparc hacks)
> c) Also think about the work needed to turn that code into
> r3000 friendly code. Should not be too much as I've done
> the "write it on recent architecture design then backport
> it to older design which had some limitations" already and
> this didn't end up being so bad.
>Expect more as I think it up... this should keep you guys busy for
>(Any dead-head tape traders at SGI engineering? Just wondering, may
> want to start talking to them now ;-)
You'll find lots of them here ;-)