timer-preempted kernel thread resumes execution in trap() after yield().
otherwise the kernel could get an arbitrary number of nested timer intrs.

also thanks to greg price.

thanks to greg price.

accessible to user from the hidden CPU segment registers.

add slides for shell, x86 intro, x86 virtual memory  (deleted JOS from slides)

I understand this one.

bda[0xE] is a 16-bit segment number,
not a real address.  So shift 4.

Reported by Silas.

Jim McKie says this code only matters
on ancient EISA MP systems.

Model verifying that wakeup really
can be called after release without
causing deadlock.

Incorporate new understanding of/with Intel SMP spec.

Dropped cmpxchg in favor of xchg, to match lecture notes.

Use xchg to release lock, for future protection and to
keep gcc from acting clever.

Re: why cpuid() in locking code?

rtm wrote:
> Why does acquire() call cpuid()? Why does release() call cpuid()?

The cpuid in acquire is redundant with the cmpxchg, as you said.
I have removed the cpuid from acquire.

The cpuid in release is actually doing something important,
but not on the hardware.  It keeps gcc from reordering the
lock->locked assignment above the other two during optimization.
(Not that current gcc -O2 would choose to do that, but it is allowed to.)
I have replaced the cpuid in release with a "gcc barrier" that
keeps gcc from moving things around but has no hardware effect.

On a related note, I don't think the cpuid in mpmain is necessary,
for the same reason that the cpuid wasn't needed in release.

As to the question of whether

  acquire();
  x = protected;
  release();

might read protected after release(), I still haven't convinced
myself whether it can.  I'll put the cpuid back into release if
we determine that it can.

Russ