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

[Sebastian Huber]

On 11/13/2012 04:06 PM, Sebastian Huber wrote:
> On 11/13/2012 03:41 PM, Ralf Corsepius wrote:
>> 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.
>
> Can you please explain this.  How do I assassinate multilibs?
>

Multilibs are a set of libraries provided by the tool chain.  Part of this 
libraries are the libc and libgcc.  The multilibs define also the set of ABIs 
that are available for RTEMS.  In "cpukit/score/cpu/*" we use GCC provided 
defines to determine the currently selected multilib and thus the ABI.  These 
defines are used for example to define the thread context.  The exact same 
mechanism is used in my patch to determine the pointer size.  See also

http://www.rtems.org/pipermail/rtems-devel/2012-November/002003.html

This is also the reason why my patch is an improvement over the Autoconf 
generated __RTEMS_SIZEOF_VOID_P__.

What do you mean with "assassinating multilibs"?

How do you solve the problem of pointer size dependent load/store machine 
instructions in your elusive inline asm?

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

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