Re: G4 support?

["Brian C. Grayson" <bgrayson%marvin.ece.utexas.edu@localhost>]

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.

  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.

  I'll keep y'all posted on my G4 efforts...

  Brian