On Thu, Aug 02, 2018 at 10:56:11AM -0600, Simon Glass wrote:
+Tom
Hi Masahiro,
On 30 July 2018 at 19:41, Masahiro Yamada yamada.masahiro@socionext.com wrote:
2018-07-26 22:59 GMT+09:00 Philipp Tomsich philipp.tomsich@theobroma-systems.com:
With the ram-size variable changed to u64, we'll need appropriate macros for printing u64 values correctly either in 32bit builds (i.e. ILP32 models) or in 64bit builds (i.e. LP64 models). Best to make the PRIx64 macro available everywhere.
This include inttypes.h from common.h to make the various macros for formatted printing available to everyone.
Signed-off-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com
NACK.
PRIx64 is evil crap. I would make the code super ugly. Do not use it.
The right thing to do is use the same typedefs for all architectures.
typedef unsigned char u8; typedef unsigned short u16; typedef unsigned int u32; typedef unsigned long long u64;
This works for both ILP32 and LP64.
Use '%llx' for printing u64 variables _always_.
This is what Linux exactly does.
In fact, Linux defined fixed-width types differently for different architectures in old days.
After long time effort, Linux unified the fixed-width types for the kernel space.
https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/int-l...
See Linux commit:
commit 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf Author: Geert Uytterhoeven geert@linux-m68k.org Date: Thu Jan 23 15:53:43 2014 -0800
asm/types.h: Remove include/asm-generic/int-l64.hAnd, I fixed ARM Trusted Firmware in the same way:
https://github.com/ARM-software/arm-trusted-firmware/commit/0a2d5b43c81ed613...
U-Boot is still doing wrong, and core developers in U-Boot do not understand this, unfortunately.
While this works in many cases we do seem to have problems with some toolchains. Perhaps things are better now as my problems were a a few years back. Things like size_t with %z caused problems too. I remember m68k producing warnings when I tried this.
I am certainly interested in converting over to this other approach. I am also OK with the PRi stuff, since it only affects a relatively small number of cases.
It would certainly be worth giving things another try with current compilers.