Hi Mike,
On Fri, Aug 19, 2011 at 12:19 PM, Mike Frysinger vapier@gentoo.org wrote:
On Friday, August 19, 2011 14:07:16 Simon Glass wrote:
On Fri, Aug 19, 2011 at 9:14 AM, Mike Frysinger wrote:
On Friday, August 19, 2011 09:47:04 Simon Glass wrote:
+static int spi_flash_update(struct spi_flash *flash, u32 offset,
- size_t len, const char *buf)
+{
- const char *oper;
i wonder if there'd be any code size difference if we had: static const char * const opers[] = { "malloc", "read", ... }; const char *oper; ... oper = 0; ... ++oper; ... ++oper; ... printf("...%s...", ..., opers[oper]);
i hope it'd be slightly smaller as you would be loading up a small int in the for loop and not an entire pointer ...
It's exactly the same code/data size on ARM, but perhaps smaller on a different architecture. I like that approach anyway so will change it.
i know on Blackfin at least, doing something like: i = 0; will expand into a 16bit insn: R0 = 0; and the follow up: ++i; will be another 16bit insn: R0 += 1;
while something like: void *foo = "foo"; will expand into two 32bit insns: P0.L = _some_label_for_string; P0.H = _some_label_for_string; and since there will be no known relationship between the diff strings at the C -> asm stage (since string placement is done by the linker), each string load will be a sep pointer load.
i imagine that the normal ARM insn set sucks at this kind of code density, but i'd think their reworks (like thumb and friends) would be much better.
Well it's just a literal pool access on ARM, so a single instruction on both ARM and Thumb. Not sure how else the compiler would do it...
do we leverage thumb at all in ARM u-boot ? or am i crazy/stupid for thinking this could possibly be a good thing ? -mike
No we don't. IMO if available we should use Thumb 2 instead of ARM most of the time - it is a lot smaller and runs about the same speed.
Regards, Simon