From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 23 Aug 1995 11:31:20 -0400
From: Berry Kercheval kerch@parc.xerox.com
Subject: Set User (aka su)
Topicbox-Message-UUID: 1b2c1672-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19950823153120.6wcdUCeERGLLUFq0TOxJw7ogrB85iH1WMFPSMN4_F4w@z>

>>>"Nigel Roles" said:
 > > I hate to find myself in the possible position of defending Sun
 > > on this one, but I would like to point out that there were two very
 > > significant reasons for this: (1) folks didn't expect that performance
 > > would be an issue, and (2) the code involved was interpreted forth
 > > running from EEPROM which require 1 usec/byte fetch.  It doesn't
 > 
 > Why is interpreted Forth a defence? Sounds more like a plea bargain.

Interpreted Forth is not the defence, it's the excuse.  The defence is most
people don't live in the raw console; they start some kind of window system
immediately upon booting; some even start it automatically.

And, by the way, it's not just the interpreted code that makes it slow; the 
raw console bitmap font lives in that EEPROM too, and the stock console
driver hits it for every row of every character.  

A friend of mine wrote a little program that copies the code to RAM and forks 
a new shell for you; this makes running on the console ENORMOUSLY faster.  I
like to use it when I'm debugging a driver that I expect to crash and 
don't want to take the time to start X up.

Later Sun EEPROM code does this (copy font to RAM) too; it may even copy out 
its own code, I'm not sure.  It gets a lot snappier.

....but this is all irrelevant to 9fans.  Maybe when my CDROM comes I can 
be more relevant :-)

  --berry

Berry Kercheval :: Xerox Palo Alto Research Center