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.masah...@socionext.com> > wrote: > > 2018-07-26 22:59 GMT+09:00 Philipp Tomsich > > <philipp.toms...@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.toms...@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-ll64.h > > > > > > > > See Linux commit: > > > > commit 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf > > Author: Geert Uytterhoeven <ge...@linux-m68k.org> > > Date: Thu Jan 23 15:53:43 2014 -0800 > > > > asm/types.h: Remove include/asm-generic/int-l64.h > > > > > > > > > > > > And, I fixed ARM Trusted Firmware in the same way: > > > > https://github.com/ARM-software/arm-trusted-firmware/commit/0a2d5b43c81ed6132761023bf43755f13122ddf0 > > > > > > > > > > > > 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. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
