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

[Thomas Doerfler]

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_. His intention
is not to turn time back. 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.

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.
> 
>> 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. 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.
> 
>> Maybe the whole discussion would become more transparent, if a
>> certain piece of code is transformed the way you seem to vision.
> OK, please provide me with a piece of code to look into. (No, do not
> point me to Joel's smp macros - They are implemented in a way, they a
> FUBARed).

You may have seen the snipplet Sebastian has pointed to in this mail
thread. We will provide you a proper piece of code soon.

wkr,

Thomas.

> 
> Ralf
> 
> 
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Obere Lagerstrasse 30
D-82178 Puchheim
Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax: +49-89-18908079-9
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.