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

[Cedric BAIL <cedric.bail@free.fr>]

> 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.

In that case it can be very interesting for us to know that.
 
> > 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 ?...

Sorry, I must go back to home (a stupid electrical problem with my
server...)

> >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.

Hum, the question was : wich form ?
 
> >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.

From what I remember you can find this into this tex file :
http://f-cpu.seul.org/cedric/F-CPU_manual-0.2.6-en/src/i7/Draft/Memory/loadi.tex

> > 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 ?

No, from what I think it's a bad idea.

> >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.

I will mark it, like all the instruction that are not yet implemented as
subject to change.
 
> >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 ?

False, "loadcons Imm64, Rd" is in the manual, and I think it must stay in
the manual for compatible assembler. Same idea for loadaddr (NicO: I dont
like the dot prefix for an instruction because it isn't really a macro, it
must be treated by the assembler like a unique instruction for relocation).
 
> >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\

Write a simple .txt file and send it. I will do the rest.

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