[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> >> there are several F-CPU assemblers now.
> >> even though i don't know which one to trust :-P
> >> everyone with a specific syntax, unique features etc ...

> >:) Are there reasons other than personal ego ? Like

> >if all wants their own assembler ? And are these
> >documented so that I can select one ?

We are planning to do a documentation for our assembler, but it take a lot of 
time to write it (more than to code it in fact ;-).

> >> emulator is a big problem. it will take time
> >> before it's completely solved but i am confident.

> >I understand that it is a big piece of code. But is
> >the principle so hairy ?

> "in principle, no" :-)

The problem is that currenlty we didn't define how to setup hardware 
interruption and interface with the rest of the world.

> One of the big limitations is C itself.
> handling the large SIMD data is not easy, so a library
> must be designed ... C is limited to 64-bit data
> but not F-CPU, which can be configured to handle larger data.

That's not really a problem.

> > Probably memory and cache simulations are not so simple too.

> if we ever go to that point ....

We must thing to that when we are writing to code a emulator or we will need 
to rewrite it totally if something change. A good idea will be to have a 
configurable memory hierarchy so that we can test the impact of different 
cache policy on a complete system... But that's a dream... or a nightmare ;-)

> >I wanted to port linux also because when it "runs" you
> >can benchmark other code on it (like to compile gcc on it).

Something that will be very interesting will be to use cycle counter for 
benchmark so that we can have an image of the final result. So some tools 
must be rewriten.

> >So I wanted to say that I have to add all others like
> >logic, other shifts, rots ....

It will be perhaps a good idea to put it on a cvs, so that some other people 
can help you.

> >> the 'trick' is maybe to use a "macro" and the instruction
> >> can be rescheduled by Cédric's assembler ...

I don't think it's a good idea, because the assembler can only do limited 
scheduling. The compiler can schedule thing before allocating register, 
something that the assembler couldn't do.

> i thought that loadconsx could do the trick...

loadconsx has been removed since 0.2.5 or 0.2.6, I think it was because we 
have widden. But I think a loadconsz that will zero the other chunk can be 
useful.

> >which is without possible stall. Of course the "stall" slot
> >will be probably used by compiler but not always. Do you
> >know better code for small negatives ?

I was thinking that 8 bits immediates were signed. For other you need to use 
widden, but I was thinking that it only take one cycle. So I don't understand 
your stall.


Cedric

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