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

[devik <devik@cdi.cz>]

Hi,
I deleted some parts and answered them in reply to cedric's mail.

> >I didn't know about past efforts ! Huh... I could
> >starts from that and not from scratch then :(
> have a look at http://www.f-cpu.de/gcc/

sure :)

> >I planed to stole HW emulation from bochs :)
> huh....
> do you really need to put some x86-related things in F-CPU ?...

no x86 related parts - I was thinking about PCI subsys,
IDE, text video and keyboard. But the very first attempt
could probably go with pooling "HDD" thru fixed memory location
and VT100 console at "serial" port simulated in the same
way.
Then you could simply attach /dev/console of fcpu linux
to the serial port and other side (emulator's) connect
to PTY of host machine - then simply run xterm and have
both video & keyboard :) Probably the fastest way to code.

>[...]
> >in moveM which is unfortunately not allowed when
> >reload_in_progress is true. Have you played with these ?
>
> if at least i knew what you are talking about ....

ehh ok, I'm not sure I know it either :)

> >I use only zero and not-zero accompanied with cmpxx. I didn't
> >use MSB because there was discussion about its removal and LSB
> >because I don't know good use for it yet ;-)
>
> The problem with MSB is : how to deal with the cases
> where F-CPU implements, say, 128-bit registers ?
> until now, it's hardwired to bit 63 of the registers
> (that's the sign bit ...) but i don't know what will
> happen next.

I understand. And LSB ? Do you have some use for compiler in mind ?

> >> >    bseti log2(1048576),r0,a0
> >>
> >> wow .... uh ....
> >
> >I was lazy to use "*" in define_expand instead of "@" to
> >compute "log2_exact()" so that I simply emit it for assemler
> >to handle it ;-) I use bseti C,r0,r for constants over 0xffff
> >which are powers of two.
>
> i'm not sure it's going to be implemented soon (the shifter
> is already quite large and i'm less optimistic about inserting
> more logic in the critical datapath). But it can be macro'ed
> anyway...

Ahh are you speaking about bitop insn ? Would be possible
to implement it as second pipeline stage after shift ? Not
that I would need it - I only want to understand if it is
possible without larke consequences (next port to xbar or so).

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

it was dropped ...

> must be implemented (like : reducing the overhead of the
> prefetches, the number of pointers, etc ...)

number of pointers ?

devik

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