[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] about register mapping
Le Dimanche 11 Janvier 2004 19:46, Christophe Avoinne a écrit :
> 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
> 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
> 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
> as possible.
For something as slow, the best is to use a simple fifo where you could
program when an it is raised depending of the number of byte inside it. The
the cpu (or a dma) could transfert a block of data.
That's the simplest and the most efficient. You could find it in some section
of "continuous rediscover great feature" in some hardware website.
> 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
> 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 ?
A special "in-order" flag of a page of the VM could be used. I think that mtrr
do this job on x86. It does not do prefetch and out of order read/write.
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/