On Fri, Aug 19, 2011 at 12:57 PM, Mike Frysinger <vap...@gentoo.org> wrote: > On Friday, August 19, 2011 14:25:46 Simon Glass wrote: >> On Fri, Aug 19, 2011 at 12:19 PM, Mike Frysinger 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... > > i'm not as well versed in ARM lingo as you to understand what "literal pool > access" means ... > -mike > Hi Mike,
:-) It's just a pool of literals, basically in this case a list of string pointers, placed close to the PC address so that you can easily access them with a PC-relative load. It's not an ARM think though - lots of CPUs use them. The alternative is to encode the full address in the instruction, so I suppose it's this: ldr r0, fred (which turns into ldr r0, [pc, #offset of fred]) fred: DCD 0x12345678 instead of: mov r0, #0x12345678 Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot