"Butter bei de Fische" was: Re: [PATCH v3] score: PR1607: Add and use CPU_SIZEOF_POINTER

[Ralf Corsepius]

On 11/13/2012 03:19 PM, Thomas Doerfler wrote:
> Ralf,
>
> Am 13.11.2012 14:25, schrieb Ralf Corsepius:
>> On 11/09/2012 08:44 AM, Thomas Doerfler wrote:
>>> Ralf, Sebastian,
>>>
>>> we had that discussion for a long time now, with different flavors.
>>
>> Correct. Eliminating such POINTER_SIZE stuff was one of my first
>> achievements when getting involved into RTEMS.
>>
>> What Sebastian is trying to do now, to me means turning back time by ca.
>>> 10 years ago.
>
> Sebastian is trying to solve real world problems _today_.

I'd call it hacking.

> His intention
> is not to turn time back.

It's what he is proposing.

To put it drastically: He is assassinating multilibs.

> His goal is to adapt assembly code to
> architecture derivative differences without loosing performance and with
> an automatism to detect discrepancies between compiler and assembler code.
... Code please ....!!!!

> It may be, that past code had more parallel definitions in C and
> preprocessor/assembly than needed, but I have not yet seen a method to
> use different assembly mnemonics in a assembly sequence depending on the
> machine's address range (e.g. 32/64 bit) without preprocessor interaction.

Right, it's exactly what preprocessors are for. The issue with 
Sebastians proposal is the way he is deriving the defines and the way he 
is propagating them into headers.


>>> From
>>> my knowledge of the PPC assembly code snippets, I can't see how we can
>>> come along without preprocessor symbols specifying the pointer length
>>> (Well, we might hard code it to 4 bytes, but that is not what we want...)
>>
>> You can pass _constants_ as parameters to c-inline asm.
>
> On inline assembly level, I can't use constants to switch to different
> assembly instructions.
Right, but you can derive the sizes of types required by eg. address 
arithmetics.

> Neither can I modify a whole sequence of assembly
> instructions depending on passed in constants. Surely we can drop some
> of the optimizations in task switching code, but this will mean to slow
> down the system and work less energy efficent. I wouldn't like to see
> these disadvantages incorporated in RTEMS.
>
>>> Ralf, you seem to have a concept in mind how that code could be written
>>> in a way, that is based on inline asm support instead of preprocessor
>>> macros.
>>
>> Yes, but it's a long time ago, since I did this and do not recall all
>> glory details (I did a mass conversion as part of the
>> campaign/initiative mentioned above).
>>
> Hint: Part of the project cooperation should be to rely on the different
> knowledge each person can provide to the project. If you haven't really
> worked on assembly level for a long time, you might consider, that
> people doing this every day may have some insights that you do not have.
Hint: You are destroying my works and are destroying RTEMS source-tree 
structures/design.

May-be these structures and the design sucks? Then it's time for me to 
draw consequences.

Ralf