Re: Re: [f-cpu] F-CPU project and Debian

[whygee@club-internet.fr]

hi !

De: Cedric BAIL
>> hi,
>> 
>> i just got a mail from Russell Coker and here is the answer i sent
>> him.
>> Your comments are welcome, maybe i wrote something silly....
>> However, before you flame me, please read until the end (the
>> "white list" idea).
>
><I read all, but it's long so snip all ;-)>
yep, but i hope it was not boring anyway :-P

>I don't know if it's this is a good idea to start from distribution, before
>having the CPU... or a simulator.

what i simply propose is to review the existing packages
and have a first list of software that can be recompiled
without modification (provided the libraries and compiler
are adapted too). The package maintainers can indicate
us what ports to ALPHA and SPARC-64 created problems and
what kinds of problems they found.

When the white list is done, we will have a first idea
of what problems to solve, and what can be already used
(recompiled) immediately. It is as simple as that for me.

> Perhaps it will be a good idea if you can
>send me a list of new opcode/instruction for ROP2 before starting helping
>porting debian ;-) Or give me a pointer to your latest package.

ouch....
can we meet this week-end ?...

>In the same idea for the new instruction ll/sc for emulating CAS/CAS2 on
>a single processor what are the mnemonic and the option.

i am currently investigating the idea (found in a discussion
some months ago) of a LL/SC unit that would work a bit
like the Load/Store Unit, but without the problems.

>I reread all instruction that use stream in the old manual, and I discover
>that if you specify the stream 0, it mean that it will use the last specified
>stream for this register.

??????????????????

it's not what i meant. stream 0 is the "default"
stream and that's all, there is no notion of a
persistent state. Unless you have found a really
good idea, which i would be pleased to read.

> The question is what append if it wasn't specified ?
>(I think that we must say that stream 0 is like the other stream so that
>we didn't have any special strange case).

The idea of a "persistent default stream" has never
come into my head. I have never found a case where this
would be useful, so i never thought of it.
Maybe your questions about streams and libraries
(which i think can be answered in several ways)
made you think about this eventuality ?

>In the same idea I will add the following instruction :
>loadz Rc, [Rm], Rd
>....
>loadnz Rc, [Rm], Rd
>storez Rc, [Rm], Rd
>....
>storenz Rc, [Rm], Rd

please mark this as preliminary and optional
for now. The LSU design is not finished and the
conditions could still change, maybe.

>And I will specify a new form for assembler :
>loadaddri Imm64, Rm
>
>Where Imm64 will be marked as a PC relative relocation, and it will be
>expanded like this :
>loadcons.0 Imm64 & 0xFFFF, Rm
>loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm
>loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm
>loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm
>loadaddr Rm, Rm

This is a macro, so it must be documented in the
assembler's doc, not in the CPU doc... right ?

>If you want to specify something it will be a good idea to say it now. I
>am planning to post a prerelease for next week.

I would like to add a small part about data types,
formats, pointers, addressing spaces. however i don't think
i have enough neurons to write it.... /o\

>Cedric
YG

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