On Fri, Aug 19, 2011 at 12:57 PM, Mike Frysinger vapier@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