tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "processor" abstraction



> A lot of systems are coming with compute/peripheral processors with
> limited ram, etc.

> I was wondering what the abstraction should be?

> Obviously, mmap()'ing their memory would be nice.  But what about
> stopping/starting?  Messaging?

> Ideas are welcome.

I would suggest something minimal, then let people develop it and see
where it goes.

As for the minimal abstraction?  Here's a strawman:

- mmap to access the coprocessor's memory
- ways (read/write? ioctl?) to do various things:
- - halt
- - single-step
- - run
- - grab processor state (registers &c)
- - set processor state

I think a harder question will be privilege decisions.  Who gets to
frob which coprocessors?  When?  How is this enforced?

Another harder question is inventing a suitable abstraction for
"processor state", especially if (eg) the coprocessor and the host
processor have different native register sizes, or there's some state
that's expensive to get/set and only occasionally useful.

What about granting the coprocessor access to host processor resources
(memory, device registers, etc)?  Some hardware may be able to do this
only in limited ways, other may not support it at all.

What about (eg) traps on the coprocessor?  Breakpoints (which are often
implemented as traps)?  What about coprocessors which lack direct ways
for the host to do some of the above?

There's also the question of how much gets moved under this umbrella.
What about, eg, the 56k on a NeXT?  What about CPUs embedded in
peripheral devices?  (Most of them aren't normally used as processors,
but some peripherals allow the CPU to give them code to run; this is
usually thought of as firmware for the device, but there's no reason it
has to be).  What about a blitter chip?  What about FPUs?

At least part of this depends on the intended application.  The only
case where I ever did anything much like this personally was with 4.3
on a MicroVAX-II which had a KA620 (a slightly tweaked MicroVAX-II) in
it as an auxiliary processor; it was doing robotics and the KA620 was
running the control law.  I built a small kernel which the host booted
on the aux; that particular implementation was heavily
application-specific, but I think it could have been done with the
above abstractions....

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index