Re: Re: Re: [f-cpu] GCC 3.1 for F-CPU port

[whygee@club-internet.fr]

hi !

>De: devik
>
>> >> at least, using these numbers is not ambiguous at all.
>> >
>> >Probably because .8 is valid ONLY if SR_SIZE_0 == 1 ...
>>
>> and what ?
>
>ehm .. if you use .8 => SIZE_BITS(00) and run with SR_SIZE_0=16 ....
>it will do something unexpected (unless assembler emit that it
>expects SR_SIZE_0 is 8) :)

well here it deals with the SR_SIZE map.

i was refering to the explicit size postfix in the assembler.
The initial question was : what syntax to use, not what it
was mapping to (what size).

It seems that the assembler will have to manage a "local
SR_SIZE" map. So if one writes .8, then the assembler
will emit the flag that corresponds to the SR containing 8.

I have had a small presentation of AASM (written by cedric
and (mostly) by his friend), and i think it can deal with
that. Unfortunately, they are reluctant to releasing a
beta version before 2 months. but i have seen it work 
so i'm confident.

>> There is also a little convention : SR_SIZE_3 contains
>> the largest size. This way, algorithms that need the largest
>> size (for maximal performance) do not need to fiddle with
>> SRs. But this can be changed or enhanced.
>
>Let me speculate a bit. You want forward compatible CPU. So
>if one compiles program for 64 bit FC0 he assumes SR_SIZE_3=64
>(or 4 or 8 - I'm not sure with semantics).
>If you now have 128bit FC0 (will it be still FC0?) then you
>could still run that program - OS loader will load SR_SIZE
>map from ELF PHDR and apply it for given task. But here
>SR_SIZE_3=64 not 128 so that the convention doesn't hold.

well, the "default mapping" is the "direct" one, which is
currently used (hardwired in the first generation of FC0).
The i think it is the task of the program itself to modify its
own SR_SIZE regs. But there still is the problem of the
libraries : they must also conform to a certain standard
concerning the SR_SIZE. That's why i proposed the SR_SIZE_3
to be set to the maximum size, easing string and other
computations (so they don't have to save the SR and restore it)

>> > I should not rely on bits 8 and higher, these can have
>> > any value, correct ?
>> now, the mask clears the MSB so you can rely on this to be zero.
>Hmm .. but then the code will not be compatible with CPUs
>which don't implement the masking.

? i don't expect this to exist. Masking seems to be the
only solution, as it was recently examined (the last version
gave too many problems, more than i naively expected)

>Will it be mandatory on all F-CPUs to clear it ?

i think so.

unless someone comes up with a crazier idea ?...

>devik
YG

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