Re: [f-cpu] about register mapping

["Christophe Avoinne" <christophe.avoinne@laposte.net>]

1°) Yann and Nicolas wrote :
> >>>But it restric the kind of interraction we could have with the device.
> >>>f-cpu tend to throught every thing in special register.
> >>>So i would like to better know pro and cons about that.
> >>
> >>There are many points to consider.
> >>
> >>First, we must NOT forget that there are "slow" I/O and "high-bandwidth"
> >>I/O.
> >
> >It is not the point too. Slow IO could be a real nightmarre to handle by
> >register mapped system. Because it slow everything down unless a kind of
> > OO system look after it.
> >Slow IO also are a nightmarre for memory mapped device but less because
> > memory are known to be slow.
>
> ok, i made a mistake here : i should have said : "low-bandwidth I/O",
> that is : only for querying status and controlling I/O, not for the data
> itself.

So how do you transfert the data ? What happen if you want to read a RS232
input data ? You freeze the computer until the data is read ? You wait for
an
iterrupt call ? (so polling became impossible) You must use a dma ? (which
could be a real mess)

I write :

1) Polling method for such a cpu is a waste of time : should not be abused
in a multi-threaded environment.

2) Interrupt method for such a cpu is also a waste of time
on a character unit basis.

3) DMA method is the best, especially for sending bytes. For receiving
bytes,
the main diificulty is to know how many bytes you need to receive to avoid
DMA starvation.

Anyway, a serial controler is needed. The most important thing is that
it must be able to handle all the stuff and to raise an interrupt as little
times
as possible.

I was hearing about your PUT/GET instructions :

One said it is equivalent to RDMSR/WRMSR, one to IN/OUT.

First RDMSR/WRMSR is not exactly like PUT/GET :
- Neither RDMSR nor WRMSR tell us which register to read/modify, instead
any  register amongst eax, edx, ecx and ebx can be read/modified by those
instruction, what helps us to retrieve more infos than you PUT/GET.

So I suppose your PUT/GET could look more like an IN/OUT. but usually
we don't use IN/OUT for CPU settings but for external coprocessors/chipsets
or card board settings.

So what are PUT/GET exactly ? they cannot be for both RDMSR/WRMSR and
IN/OUT purposes meanwhile.

2°) Yann and Nicolas wrote :
> >>So all we do now is manage "slow I/O" at the CPU core level.
> >>One has to consider :
> >> - resource protection (access rights per thread or process)
> >
> >so memory mapped are controlled by TLB. Register mapped (SR) ? by
> >user/superuser mode ?
>
> yes, for example.
> later, a finer (probably hierarchy-based) protection system
> could be implemented so certain software modules/task/threads
> can access a specific set of registers, using a mask per thread,

What a mess !! All memory protection are there and you want to create some
new
system...


I write :

huh, looking at ia32 architecture, tasks pointed by TSS have an iomap for
protecting IN/OUT ranges, which is quite different since IN/OUT is not a
true
memory mapping. However, recent boards tend to use memory mapping and
DMA instead of IN/OUT counterparts (or they reduce their use).

Quite now, I still don't understand how you plan to access registers of
external
controller. How do you plan to do so ?



*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/