change log for rtems (2010-06-29)

[Joel Sherrill]

>> The SIZEOF_VOID was implemented at your suggestion.
>>      
> As I told you then, SIZEOF_VOIDP is a portable way to implement defines
> for void* sizes.
>
> As I also told you then, using such defines is a bad design and should
> be avoided.
> I apologize for not having be clear enough, then.
>
> To be very clear: Using such defines is a bad design.
>
>    
It cannot be avoided when you want to access structure
elements from assembly code.  They are only used in C
code to define offset macros for .S files.
>    
>> It is unfortunate that files inside libcpu and libbsp need to
>> be able to have that defined just like the cpukit.
>>      
> Yes, this renders your already bad design worse.
>
>    
If it was used from C I would agree.  But they are
not used in C.
>>    I don't
>> like it either but it is NOT in a publicly installed .h file
>> from cpukit.
>>      
> Correct, infecting a public is prohibitive. I would immediately revert
> such patches.
>
>    

>> The best solution would be to have this value (by any
>> name) in cpuopts.h so it is automatically available. If you
>> can add the code to cpukit somewhere that makes this
>> value (by any name) available via something installed by
>> the cpukit, then I am happy to revert the BSP and libcpu
>> configure.ac changes.
>>
>> I really don't like them either so am happy for you to
>> propose a better alternative.
>>      
> I can't propose a better solution, because I still have not seen your code.
>
>    
Then you have not looked.  It was always in the patch that
was attached to the PR.  It underwent three revisions during
the review.  Plus I filed 
https://www.rtems.org/bugzilla/show_bug.cgi?id=1572
which pretty clearly explained what I was doing:

========================================================================
For SMP support, we need to have a per CPU data structure.  This structure
has fields like executing, heir, interrupt stack, and dispatch needed for
each CPU core.  This is accepted practice and

I have this working in a development tree along with the next steps in
SMP support.  I am cleaning up my per CPU patch so it has no SMP references.
It is the first step in SMP support and doesn't have an impact on performance.
Before I submit this patch for review, there is an issue I do not know how to
address.

The elements of this data structure must be accessed from assembly files.
We have to know the offset of these elements on a per target basis. Since the
offsets can vary based upon compiler flags and version AND they need to
be constants in the assembly file, this seemed like a good job for autoconf
to generate.
=========================================================================


Check out cpukit/score/include/rtems/score/per_cpu.h for
the definitions.  And cpukit/score/cpu/sparc/cpu_asm.S
for a typical usage.  Search for PER_CPU_ and you will
see how it is used as an offset from %l5 which is the
base address of _Per_CPU_Information.

> All you have been doing so far was to claim "I need pointer
> size-defines, who to do it".
>
> To put my position bluntly: "Using pointer size-defines is a flawed,
> broken design - You must be doing something very wrong".
>
>    
No I am not.  Accessing structure elements from assembly
is not horribly flawed.  Hard-coding the offsets is.
> Ralf
>
>
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985