Re: [f-cpu] latest gcc & immediate addressing [Was: BOUNCEf-cpu@seul.org:...] (fwd)

[devik <devik@cdi.cz>]

> > "at least" ? I suppose 32bit in needs to be "naturaly"
> > (32bit) aligned, ok ?
>
> Of course. But it's not yet clear what happens with data items > 64 bits.
> They may have to be naturally aligned, or may need only 8-byte alignment.
> That depends very much on the LSU which isn't ready yet.

> 64bit ?? Are you speaking about wider F-CPU versions ?

> > yes it is of course. But if you want compined to be able to use and
> > split them you need to descrtibe their behaviour. And the description
> > I used is perfectly valid.
>
> Except that it lacks a description of loadcons.2 and loadcons.3 :)

exactly .. lazy me :)

> > (label_ref:DI 107) is label of jump table. Here we need loadaddrid
> > even if it is not clear.
>
> Heck. gcc is a piece of shit, isn't it?

hmm maybe .. I feel it as magnificant piece of code. Because
I wrote and maintain part of kernel in paralel with my job and
family and the code is much smaller than gcc and I still have
several bug reports per week (mostly void ones) - so I know
what problem is to KEEP a project alive.
And gcc is working and is getting (slowly) better. 3.3 has DFA
scheduler which will help to schedule out post-incrementer dependency
and simulate write port contention.
Other new code solves our jump-registers. Code to do syntax-tree
based optimisations is underway.
When I faced all the things inside of gcc and all nuances of memory
coherency, aliasing, sync points of C language .....
I don't think we would be able to write functional compiler for
f-cpu from scratch in reasonable time - prove me wrong please.

devik

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