Re: [f-cpu] Re: Navier-Stokes

[Juergen Goeritz <goeritz@oekomm.de>]

On Thu, 18 Apr 2002, Yann Guidon wrote:
>> How about special register access methodology opcodes?
>> This way you define the entry point how to access them
>> but do not need to fix everything (layout, number, etc.)
>> from the beginning. Just have it read/write for superuser
>> only, one parameter being SR#.
>
>i don't understand exactly, but just in case, here is the current method :
>
>- there are only get, put, geti and puti as means to access the SRs.
>  This instruction stalls the pipeline until it is sure that there is no
>  access violation.

Okay, this it what I meant. But why stall the pipeline? It also
would be possible to just advice to use a number of NOP cycles
after critical settings. Better do an out-of-order exception on
access violation. Thus the register bank may also be implemented
in a slow mode (maybe with eeprom backup or whatever).
And
finally do exception on any non-writable bit(!). This would imply
a write mask to be delivered with the write data - just to be
sure that the bits stay free for further extension...

>- the SRs are either hardwired (read-only, for example : the mask revision),
>supervisor (read-only too, if you are not running with a suitable privilege)
>or user-contolled (for example your private size registers).
>
>- the hardwired registers provide informations to the running system, they are
>  defined during the CPU design and say how many SRs there are, what kind of CPU,
>  what is the register size, what opcodes and what units are provided...
>
>- The "superuser" registers control those features that have any impact on the
>  running system, for example the trap handler addesses, the TLB, the memory mapping...
>  Note that when it is possible, an individual "authorisation" is allowed to every
>  ressource so a pice of code can deal only with one ressource at a time.
>  A task can only reset this bit (when it is set), but not set it, to enforce
>  the system's protection. This is a bit similar to the Hurd tokens but can
>  be used in other places such as Linux as well.
>
>- The "user" registers are those which have no protection bit, for example the
>  task's private performance counters or size attributes. A user can be "granted" access
>  to a SR-controlled ressource if the super-user modifies the associated SR enable bit,
>  but otherwise all the task has is a virtual address range to play with.

Do you handle the tasks in here? That really spoils my thinking.
Task private things... for how many tasks?

>There is no specific opcode for managing that, it's all done with get/put
>and it traps if the necessary rights are not granted, that's all.

Okay, get/put are specific opcodes, are they? ;)

>> Anyway, who wants to end up programming around hardware cache
>> strategies? :-/
>nobody "wants" but there are cases (yours ?) where this becomes necessary.

Oops! Necessary??? If I can control the way the cpu handles it
it may not be necessary at all. Shrug!

>> Could probably be easier to change the cache strategy on the fly?
>
>if you want to change the cache strategy, there must be more than one
>in HW. Intel's MTRR (and the competitor's equivalents) provide a mean
>to modify the cache strategy for a fixed number of memory ranges
>(for example, the video memory can be set as write-combine and
>multi-CPU shared memory space can be set as uncachable).

Yes, generally you have lock, disable and LRU in most processors.
I was mainly talking about the aging process of the cache to be
switchable from LRU to something else. It may therefore not need
a cache flush at all.

>This is usually possible to modify this when the system is "alive"
>but there's still a risk of loosing data if you switch from one
>policy to another when you forget to properly flush the caches etc...
>But that's for the x86 world.

:-) see above. If you manage to use the same valid bits it
should not cause problems as long as it stays associative.
I didn't talk of changing the load strategy! Just alternate
strategies for identification which cache entry to use for
replacement next.

>This is possible to do this for F-CPU but i don't see the point of a MTRR-like
>system, at least for the first-generation F-CPUs. I am not exactly sure
>of what you have in mind but if it's simply changing the cache
>from write-through to write-back, do not forget that F-CPU is a multitasking
>system and a user task doesn't have to change an environmental variable
>that might impact the rest of the task's performance.

I am sometimes thinking about the 64bit generation microcontrollers
with 1TByte memory built into the SOC. :-)

>So as a rule of thumb, the FC0 has a private memory range (as fast as possible)
>and public range (uncached), and the task can specify whether to keep in cache
>or not with the "hint bit" (flush) in the load and store instructions. This
>does not impact mullti-tasking systems at all and is very simple to implement.

I see - and I appreciate the hint bit.

>> The gcc 2stage profiling optimization
>> features are not thaaat convenient to use for global...

>profiling is not often used, but it is useful in constrained real-time
>applications, such as if you want to track where your soft DVD player
>wastes time. If you have a relatively coherent program you can attempt
>to do some auto-tuning (adaptative programs) which has the advantage to
>be portable, but you often forget what "convenience" means when you are
>CPU-bound, memory-bound and ressource-bound, no ? 

I did that type of thing for more than 7 years BTW... ;-)

JG

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