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

[Thomas Doerfler]

Am 13.11.2012 15:41, schrieb Ralf Corsepius:
> On 11/13/2012 03:19 PM, Thomas Doerfler wrote:
>> Ralf,
>>
>> Am 13.11.2012 14:25, schrieb Ralf Corsepius:
>>>
>>> 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.

WHo cares what you call it?
> 
>> 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 ....!!!!

Take the piece Sebastian was providing and make it really
pointer-size-dependent:

http://git.rtems.org/rtems/tree/cpukit/score/cpu/h8300/cpu_asm.S

--------------------------
SYM(_ISR_Handler):
#if defined(__H8300H__) || defined(__H8300S__) || defined(__H8300SX__)
	mov.l	er1, at -er7
	mov.l	er2, at -er7
	mov.l	er3, at -er7
	mov.l	er4, at -er7
	mov.l	er5, at -er7
	mov.l	er6, at -er7
	
/*  Set IRQ Stack */
	orc		#0xc0,ccr
	mov.l	er7,er6		; save stack pointer
	mov.l	@ISR_NEST_LEVEL,er1
	bne		nested
/* addition from Thomas for illustration starts */
#if (__RTEMS_SIZEOF_VOID_P__==2)
	mov.w	@INTERRUPT_STACK_HIGH,er7
#elif (__RTEMS_SIZEOF_VOID_P__==4)
	mov.l	@INTERRUPT_STACK_HIGH,er7
#endif
/* addition from Thomas for illustration ends */
	
nested:
	mov.l	er6, at -er7	; save sp so pop regardless of nest level

--------------------------

Note: I did not test the "illustration" purpose, but I am sure it can be
implemented in a similar way. Can you switch between a "mov.w" or a
"mov.l" in your recommended method? Or how do you map CPU variants with
different pointer sizes (e.g. i386/32 and i386/64) to their proper
mnemonics in their proper places?

> 
>>>> 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.

...which costs runtime. In every task twisch and interrupt entry/exit.
Goodbye to performance...
>> 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.

The RTEMS source is no momument. Neither for Joel, nor for anyone else
in this project. Many people have provided their share to the project
(for then good and for the bad). But this should not keep us from
adapting RTEMS to the requirements it has to fulfill.
> 
> May-be these structures and the design sucks? Then it's time for me to
> draw consequences.

I am not in a position to judge about this.

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.