Subject: Re: G4 support?
To: Brian C. Grayson <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 07/06/1999 11:36:05
On Sat, 3 Jul 1999, Brian C. Grayson wrote:
> On Fri, Jul 02, 1999 at 09:28:49AM -0700, Bill Studenmund wrote:
> > From there try boot fd:0 or maybe boot:1,%boot.
> On one of the beige ones, OF did a "CLAIM failed" for 'boot
> fd:0', and when we did 'boot:1,%boot' it went into MacOS. But
> I think I may have put in an extra space in there by mistake --
> 'boot :1,%boot' now that I think of it.
You'll need to say "boot <where>" - you need the space.
If it booted into macos, then what happened is that it got upset with what
it found, and rolled over to the macos boot.
> All the blue-and-white boxes were in use today, and they don't
> have floppy drives anyway.
> I'll probably try the non-spaced boot:1,%boot next time I'm in,
> and if that doesn't work, I can see about setting up
> netbooting, but it looks like enough steps that there's no way
> I'll get it working!
> I'll keep you posted.
> In other news, one of my co-workers and I were wondering what
> would be the best way of saving the AltiVec registers at
> context switches? The way I see it, there are at least four
> options (these are brief descriptions, not meant to be complete
> but rather give an idea of what we've been discussing):
> 0. Save the registers at every context switch, regardless of
> whether or not the process is actually using them. (Extra work)
> 1. Initially, start with every process having AltiVec disabled.
> At the first AltiVec-insn exception, mark the process as using
> AltiVec, and when it is switched out, save the state. (Extra
> work, if no other process is using AltiVec) Record the
> AltiVec-using fact as a bit in the struct proc, so that on
> context-switch-in, we know to restore AltiVec registers.
> 2. Initially, same as before. However, on context switch, don't
> bother saving the AltiVec registers -- simply remember which
> process they belong to. When we start up/resume the next
> process, disable AltiVec support. If/when some future process
> tries to do an AltiVec insn, it'll trap, at which point we know
> to save the register values to the previous AltiVec process,
> and either zero-out or restore the current process' AltiVec
> registers. (Saves excess copying at context-switch time, but
> means that every restart of an AltiVec-enabled app will cause
> an exception at the first AltiVec insn for that time slice)
> 3. Like the above, except, rather than resuming processes with
> AltiVec disabled, resume them with their previous AltiVec
> state. Also, if the previous process was AltiVec-using and so
> is the next one, then save and restore appropriately. If the
> previous was not AltiVec, then only restore if needed by the
> incoming process. If the previous was AltiVec, but the next
> isn't, then we can delay saving for the previous process until
> either a) this next process (or another future one) starts
> using AltiVec, or b) we context-switch in a different process
> that has already used AltiVec, and thus needs its state
> Whew. I'm not sure if that made any sense. Basically, we're
> trying to minimize unnecessary save/restore of AltiVec, since
> it takes around 32 cycles to save all 32 vector registers. But
> we also want to minimize unnecessary AltiVec-disabled exceptions.
Options 2 & 3 are forms of lazy fpu switching, which I think we already
do. I'd vote for either 2 or 3. Probably the best thing to do is look at
what we do with FPU context switches, and do the same w/ AltiVec.