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
>   restored.
> 
>   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.

Take care,

Bill