Re: Re: [f-cpu] optional SRB

[whygee@club-internet.fr]

hi,


>> >Of course, the IRQ/trap/syscall handler should actually store the
>> >SR somewhere else as soon as possible, so as to avoid crashing if
>> >the handler itself is interrupted (besides, the OS would take care
>> >that all handlers are locked in memory - i.e. can not be swapped to
>> >disk).
>
>> >This is much simpler than making the SRB mandatory.
>
>> and that's "RISC" ;-)
>
>Hum, are you sure ? I never see SR used like this before...

SRs are meant for special situations.
Even if traps can happen at a high rate,
it does not involve the application program.

>> cool ! someone who understands the basics ;-)
>> ok, there might be some hidden costs.
>> it might not solve everything, but it addresses most problems.
>> and it doesn't sound difficult to implement.
>
>It doesn't address the most important problem, preserve all your register.

AFAIK, in practice (working systems) it is done by SRB.
Now if you want to disable it, or deal with special cases
(like, huh, now, because we don't have it yet) then the
SRB's SRs can be reused for storing the first data.
Concerning the backup itself, it can be done by the compiler
on a case-by-case basis (backup the register just before
it is first used).

>> PS : i recently attended a conference about GNU/Hurd and i have
>> seen some Hurd sourcec code. It's very far from POSIX but
>> one of the most crazy things i've seen is ... mmap() used for doing
>> a malloc() .....
>
>It's all you remind about it ?
No ! i wrote : "most crazy things i've seen".
There are some "good" things, i agree, but the good principles
are hidden by the implementation problems.

> I don't wan't to make a list of the idea they 
>give about Hurd, but it's really the first OS where I see some new and 
>interesting idea (fakeauth, IPC jail, ...).
good ideas are abundant today ....
Now the problem is to "master the technology".
Too many new things are difficult to handle at once.
"Many projects failed because they wanted to
introduce too many groundbreaking technologies"
which are less easily accepted and understood.
GNU/Hurd did not fail "yet" :-) I simply hoped
that the bridges to the mainstream Linux word
were more important.

However, i know that the Hurd crowd is
definitely hooked to the idea of using F-CPU.

> A lot of good idea, but a lot of 
>work (That's remind me something, but what ?).

no idea ...... really ;-)

>Cedric
YG

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