[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] about register mapping
sorry i forgot to answer this email,
many important things need to be explained
and sleep deprivation is not a good way to
write good explanations .... here i give a second try.
Nicolas Boulay wrote:
Le Jeudi 1 Janvier 2004 20:41, Yann Guidon a écrit :
Nicolas Boulay wrote:
Memory mapped register to speak to device is a good way to extend easly awhat do you mean by "Memory mapped register to speak to device" exactly ?
Do you mean that I/O is memory-mapped ? If so, then history says that
it always end up in a big mess, look at the Ralph Brown lists
That's the way all design goes.
Because it the simple way to add peripherals to an existeing cpu.
"easy", probably, but not "best".
The question was better how to access efficaly
ispell coredumped on "efficaly"
to the TLB, DMA, clock which are low level but are very often seen in both
possibility memory mapped or register mapped.there is no doubt that these particular examples (TLB, DMA and clock)
are CPU-dependent resources
and must therefore be tied to the CPU, so a multi-CPU computer has no
delicate situations to handle.
the "PC mentality" has leaked everywhere and certainly impacts all other
http://www.cs.cmu.edu/~ralf/interrupt-list/inter61d.zipThat's a PC problem.
files Port.a, Port.b and port.c
For example, port 0x300 was "reserved" for prototype cards,
but today it is used by more than ten "commercial" cards
and probably much more, since the RBIL can't list everything.
Fortunately, the PCI standard reduced the pressure on the I/O port
addressing space with providion for dynamic address allocation
i want to make sure that this does not impact the F-CPU project in a
i say : "tainted".
but the "legacy" remains : the PCI standard is and will remain:) PCI is used everywhere and is not tied to the PC at all.
tainted by the original PC-XT definition.
i know that there are PCI slots in almost all new computers, even non-x86
but the basic definition of the PCI standard contains several x86 and
if i was not lazy to spend 5 minutes on google to search the examples,
i would drop a few URLs.
The morale is : if it is possible to do something messy, it will become
a mess. Even if you make something a bit better later, it's too late.
Nooo ? sans dec' ?
si j'tel'dis ....
If I/O boards, or even any board is to be designed, then it would beAll of this is how to deal with memory mapped IO. That's out of topic here.
better to use a few wires for a I²C or SPI bus. When booting,
the main CPU will read the parameters from a serial EEPROM
and configure the addresses and other internal registers.
But it is not a panacea, because the main CPU needs a "device driver"
in order to interpret the embedded parameters. This could cause
more problems (CPU compatibility etc.) than it solves.
i thought it was indeed on topic,
as i tried to imagine a system that would address our concerns.
ok, i made a mistake here : i should have said : "low-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.
But it restric the kind of interraction we could have with the device.There are many points to consider.
f-cpu tend to throught every thing in special register.
So i would like to better know pro and cons about that.
First, we must NOT forget that there are "slow" I/O and "high-bandwidth"
Slow IO also are a nightmarre for memory mapped device but less because memory
are known to be slow.
that is : only for querying status and controlling I/O, not for the data
i did not address the "access time" of the register itself, only its
High-bandwidth requires specific hardware that performs the data movesNop this is fast. Why a DMA will be slow to be configured ?
(a sort of DMA). Configuring this DMA typically requires "slow I/O"
access to the
because i made a mistake in the naming.
you coud try to find a better name.
address registers (source + destination) and count register for example.Yep and most of the time it come with the device.
But this could be much more complex for ATA/IDE, USB or SCSI.
The DMA for fast I/O is not yet studied for F-CPU because it depends on
the kind of peripheral : Disk, network, even video. The DMA engine for each
case is best examined globally, and defining a "one-fits-all" DMA engine
could cause problems if a completely new kind of peripheral is created.
So all we do now is manage "slow I/O" at the CPU core level.so memory mapped are controlled by TLB. Register mapped (SR) ? by
user/superuser mode ?
One has to consider :
- resource protection (access rights per thread or process)
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,
but a simple user/superuser method is enough to get started.
For F-CPU, we need something both simple and very flexibleNop :) It's much easier to do the opposite. A flag on tlb could say ordered or
not ordered access. I had looked at openrisc 1000 to see how they do it.
Since it's not defined in F-cpu, yet. We could inspired from them.
that does not interfere with the rest. It is not impossible to
use memory-mapped I/O but their absence makes it easier
to design a simple high-bandwidth memory bus.
i'd rather not spend time on it, due to potential
patent problems with MIPS ...
Furthermore, the CPU core and probably some integrated HW???
need a way to be configured : for example, the clock generator,
or the external memory banks (SDRAM for example) need
some tuning and probably run-time modifications, so it does not
make sense to go through the whole memory hierarchy to manage that.
if you speak to the onchip SDRAM controller,
why bother with the caches, addresses and all the other stuffs
when you can access the registers directly in ordered way ?
The GET and PUT instructions in F-CPU are similar to theIn and out are alias for read/write on the "I/O bus" of the x86. This io bus
is the normal bus + a bit saying "we make a IO transfert". So in fact, it's
like a adresse bit !
RDMSR and WRMSR instructions for x86 (they are local to the CPU).
IN and OUT are other instructions that apply globally to the system.
it was something like that in the 8080, 8085, 8086 and maybe 80286
but today, and at least since the P2 core, it's different considering
address space (64K max), strong access ordering, memory buffers
and many other subtleties that don't make it a real memory.
There is also a similarity with the "coprocessor" instructionsSo modest... :)
of the MIPS and ARM architectures which are used to
configure the internal registers (memory protection/TLB,
I think this mail gives some ideas to discuss about but
i guess that you (nicO) have heard and read enough on
the matter of SRs to know the principal pros and cons
of this approach, since you have argued about it.
Here, i try to give a deeper insight and a general
overview, without saying "what shall and shall not be done",
but only "what is".
don't feed the troll, design instead.
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/