MEM_STATIC and alignment
Liam Fitzpatrick
characters is allocated:
ee_u8 static_memblk[TOTAL_DATA_SIZE];
and later used in core_list_join.c (e.g. in core_list_init()) as an array of
list_head structures.
Unfortunately this gives no protection for different alignment requirements
of the different types, making the program incorrect.
I'm using v1.01 and wonder if a fix is available?
Best wishes,
Liam
--
Liam Fitzpatrick, Software Engineer, Associated Compiler Experts bv,
De Ruyterkade 113, 1011 AB Amsterdam, The Netherlands.
Tel: +31 20 6646416, Fax: +31 20 6750389
mailto:li...@ace.nl, http://www.ace.nl.
Shay Gal-On
Please use a compiler switch to force alignment on an 8 byte boundary.
For example, with gcc, you can add to the core_portme.h the line:
#pragma pack(n)
Other compilers may use command line switches, or linkers can take as a
command line or in a map file specific address to put a symbol.
Thanks,
- Shay Gal-On
Dr. Software Engineering, EEMBC
www.eembc.org/contact
--
You received this message because you are subscribed to the Google Groups
"CoreMark" group.
To post to this group, send email to core...@googlegroups.com.
To unsubscribe from this group, send email to
coremark+u...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/coremark?hl=en.
Liam
Thanks for the suggested workaround of this subtle bug in the
benchmark.
Have you any timeline on when a corrected version will be released?
Regards,
--
Liam Fitzpatrick, Software Engineer, Associated Compiler Experts bv,
De Ruyterkade 113, 1011 AB Amsterdam, The Netherlands.
Tel: +31 20 6646416, Fax: +31 20 6750389
mailto:li...@ace.nl, http://www.ace.nl.
Shay Gal-On
This is not a bug in the benchmark and there will be no correction. This is
a platform specific issues that should be dealt with using the core_portme
(either .mak if using flags to the toolchain, or .h if passing pragma
directives).
If you have alignment issues on the platform you selected, the procedure
below should alleviate the concerns. There is a reason you can modify the
core_portme files - to deal with platform specific issues.
If your toolchain does not have any way to define alignment, please use one
of the other methods for allocating memory. Which toolchain are you using
and what is the target platform btw? Can you share your port folder?
Liam
thanks for the quick reply.
It seems to me to be a portability bug, as C does not impose these
portability requirements and an implementation is not required to
either.
According to the FAQ, CoreMark is not system dependent, therefore it
functions the same regardless of the platform (e.g. big/little endian,
high-end or low-end processor). Does memory layout really not fit in
there?
One commonly approach to dealing more portably with alignment is to
use a union. C requires an an object of union type is at least as
strictly aligned as the most strictly aligned member. So, if you add:
union {
list_head *align_to_ptr;
ee_u8 static_memblk[TOTAL_DATA_SIZE];
} aligned_data;
and use aligned_data.static_memblk, then the data will be aligned as
the program further expects.
Would this not be a suitable way to address this portability issue
with CoreMark?
Best regards,
Liam Fitzpatrick
Liam Fitzpatrick, Software Engineer, Associated Compiler Experts bv,
De
Ruyterkade 113, 1011 AB Amsterdam, The Netherlands.
Tel: +31 20 6646416, Fax: +31 20 6750389
mailto:li...@ace.nl, http://www.ace.nl
> a platform specific issues that should be dealt with using the core_portme
> (either .mak if using flags to the toolchain, or .h if passing pragma
> directives).
> If you have alignment issues on the platform you selected, the procedure
> below should alleviate the concerns. There is a reason you can modify the
> core_portme files - to deal with platform specific issues.
> If your toolchain does not have any way to define alignment, please use one
> of the other methods for allocating memory. Which toolchain are you using
> and what is the target platform btw? Can you share your port folder?
>
> Thanks,
> - Shay Gal-On
>
>
>
>
> -----Original Message-----
> From: core...@googlegroups.com [mailto:core...@googlegroups.com] On Behalf
>
> Of Liam
> To: CoreMark
> Subject: Re: MEM_STATIC and alignment
>
> Dear Shay,
>
> Thanks for the suggested workaround of this subtle bug in the benchmark.
>
> Have you any timeline on when a corrected version will be released?
>
> Regards,
> Liam
> --
> Liam Fitzpatrick, Software Engineer, Associated Compiler Experts bv, De
> Ruyterkade 113, 1011 AB Amsterdam, The Netherlands.
Shay Gal-On
There is more than one way to make sure the data is aligned. Many compilers
will align arrays and structures on cache line or pointer size boundary
unless you specifically tell them not to.
CoreMark allows multiple methods for dealing with different embedded system
- passing parameters, allocating memory, and even executing in a multicore
environment in a standard manner.
Some platforms do not have malloc - CoreMark allows you to use a static
memory block and still generate a compliant result. The fact you need to
make sure the memory aligns correctly does not make it a portability bug, it
simply means you need to deal with it in the portability section of the
benchmark and not in the generic code. For a platform that needs to write
directly to a UART, you need to adjust the core_portme code to tell it how
to do that. Similarly in this case for a platform that must use static
memory allocation and does by default align memory on a pointer or cache
line block, you need to adjust the toolchain parameters to allocate the
memory the way this platform needs it.
Can you please share your platform details?
Liam
It seems we're looking at this from two different perspectives, which
is making it a bit difficult to get to the root of the problem.
I'm going out from an assumption that CoreMark is a newly written
"synthetic" application, written in ANSI C where that is sensible, and
otherwise depending on library support. Given that you suggest non
standard pragmas or toolchain configuration as the appropriate way to
address it, I think we both agree that the MEM_STATIC and alignment
issue I've raised is an example where the benchmark is not written in
portable ANSI C.
I'm working with multiple platforms, some of which could also be
called synthetic. The toolchains I'm using can certainly be configured
to apply different alignment than ANSI C requires. As you mention, it
can be a useful optimization if caches or aligned loads are of
importance. So I know how to work around this CoreMark issue with the
toolchains.
If we were discussing a real world application that was being used as
a benchmark, then I'd note the alignment issue as a system requirement
for the benchmark: character arrays must minimally have the same
alignment as data pointers.
If CoreMark+MEM_STATIC has such a system requirement would you mind
clearly stating so? Then I can stop thinking of this as a
straightforward bug but as a CoreMark portability issue.
Thanks,
--
Liam Fitzpatrick, Software Engineer, Associated Compiler Experts bv,
De Ruyterkade 113, 1011 AB Amsterdam, The Netherlands.
Tel: +31 20 6646416, Fax: +31 20 6750389
> will align arrays and structures on cache line or pointer size boundary
> unless you specifically tell them not to.
> CoreMark allows multiple methods for dealing with different embedded system
> - passing parameters, allocating memory, and even executing in a multicore
> environment in a standard manner.
> Some platforms do not have malloc - CoreMark allows you to use a static
> memory block and still generate a compliant result. The fact you need to
> make sure the memory aligns correctly does not make it a portability bug, it
> simply means you need to deal with it in the portability section of the
> benchmark and not in the generic code. For a platform that needs to write
> directly to a UART, you need to adjust the core_portme code to tell it how
> to do that. Similarly in this case for a platform that must use static
> memory allocation and does by default align memory on a pointer or cache
> line block, you need to adjust the toolchain parameters to allocate the
> memory the way this platform needs it.
>
> Can you please share your platform details?
>
> Thanks,
> - Shay Gal-On
>
>
>
>
> -----Original Message-----
> From: core...@googlegroups.com [mailto:core...@googlegroups.com] On Behalf
>
> Of Liam
Shay Gal-On
Requirements are as follows:
- For MEM_MALLOC your platform needs to provide a function that will return
a buffer (malloc functionality).
- For MEM_STACK your platform needs to be able to allocate 2K on the stack.
- For MEM_STATIC your platform needs to be able to allocate the buffer on an
aligned address, or be able to load/store to unaligned addresses.
In fact, you can even implement a static buffer with MEM_MALLOC - in the
function portable_malloc() use a static array, and have it aligned via a
union, or allocate a slightly bigger array and return a pointer to the first
aligned address. That would not require you to use any compiler flags,
linker maps, or pragmas. Does this ANSI solution work for you?
If you find that MEM_STATIC is not portable for you, simply use another
method.
I can post a port folder with such an implementation if that works for you.
I do not see this as an issue that requires creating a new version of
CoreMark. A new CoreMark version will only be issued if there is a flaw
found in the benchmark that would make results on different platforms
non-comparable (e.g. platforms able to avoid executing statements at run
time), or a portability issue is found that cannot be addressed using the
mechanisms in the port folder. Any portability issue that can be dealt with
using the port folder SHOULD be dealt with in the port folder.
EEMBC may create other standard free benchmarks that target different
functionality from time to time, but there should be only one CoreMark :)
Hopefully you can use one of the methods suggested to create an appropriate
port folder for your toolchain.
Thanks,
- Shay Gal-On
Hi Shay,
--