CRUX PPC

Hello,

If we remove Lite 5200 eval board from plateform support (and leaving efika), the kernel build fail during wrapper step due to missing mkimage tool. Would it be usefull to add this tool to the toolchain?

zImage.chrp is correctly build I guess even if I didn't tried it yet.

There is a 2Kb gain removing the lite 5200 plateform support.

Czk.

EDIT :

Even if the wrapper fails with mkimage, the built zImage.chrp is working. I made an ugly fix : compiled an empty main() named mkimage to finish the kernel build. Efika is currently checking the fix with a clean kernel build.

I have a working 2.6.24.2 kernel without module of 1.576.504 bytes. How could I check if the printk are really removed from the build ?

Hi,

I don't know if this will interest someone but I think it is worth to be written.

This is a little story about size.

My fake mkimage is a main() with return 0; Doing a simple gcc mkimage.c -o mkimage give me a rough 9.5Kb executable. I found this fat for a simple return 0 program. Don't you think ?

Digging further with gcc options...

Add -Os make me gain 40 bytes.
Add -s for stripping make me gain 5Kb.

Still 3.5Kb fat for a simple return 0 program...

Removing standard lib (glibc stuff i guess) and startup code with -nostartcode -nostdlib give linking error... (_start / _exit...)

Hum.

It is time for assembly tweaking.

Compiling for assembly output. Replacing main by _start. Compiling. Segfaulting. Exit code is not good.

Current code is :

li 3,0
blr

Digging ABI.

Correct return code is not blr but sc with register 0 loaded with 1. Editing the source, replacing blr with sc, adding li 0,1. Removing comment junk and useless define (bss, data, text) stuff around code. Compiling. Runing. Working.

236 bytes long for return 0 program. Good. This is 40 times smaller.

Digging ELF file format with objdump -x a.out

Hum. Not much I can do here. Next step is hex file editing to tweak elf file format. I guess I can strip some more bytes but the current result is not that bad.

Moral de l'histoire :

- Bloated software comes with useless bytes.
- Assembly is a must have skill
- Size do **really** matter.

The less bytes i have, the more I can read, understant and ** trust ** the code.

Future is embedding and power saving. Power saving starts with lowering memory footprint : switching bit costs power. Thus, saving every bytes makes my battery stay (a bit) longer.

Czk.

ehy, that's good! You'll have a lot of fun with CRUX PPC. :mrgreen:

Yes, lot of fun. For sure. I am a bit disapointed to see how fat (without tuning) 'tollchain' build stuff. I can't trust something that put 9,5k for a **simple** do nothing and return to call point (next step : dig where the processor goes when the program return to sub).

I had just a remind from an old article i read about C optimisation. I shoud have removed the main() call and put instead a simple _start() in the C source.

The linker expect _start instead of main. _start shall be found in standard libs. I should have a look at this startup code to see what it does.

Damn. Time to dig deeper. :)

ok, i don't have cheked but it could be right. That's GCC.
I think you can pass on your hamletic doubts to gcc developers.

not really, the assembler of sparc for instance is quite different from the powerpc assembler, and each and every processor in a processor family has special features... you can't know them all and the average programmer can't know them all. The average compiler can get out of average C code better assembler code than the average assembler programmer. Of course the best Compiler cannot even get close to what the best assembler programmer can do, but you know... there is always something worst than badly compiled C code... what about java or python, or .net/mono??


IMHO power saving is not so directly tied to memory footprint as you claim, anyway i agree with you on stripping down bloat, but unfortunately the rest of the world doesn't seem to think in the same way... java, oracle, web2.0, hald dbus, that's all bloat, and unfortunately it's taking more and more over... and guess what? everyone has economical interests in that, so it's hard to fight that...

But that's not our toolchain, it's just the toolchain. i bet you can't get better results with a ppc distro with similar toolchain components (well you'll probably be disappointed more by other distros ;)). If you really want to go embedded size, you should switch to uclib. Crux-PPC is a general purpose distro that is somehow adaptable to light-embedded solutions, but is not for hardcore-embedded, so it can't live with uclib, dropbear and busybox.
Anyway the simple-do-nothing-program includes the runtime that is fixed size, and it's weight will be much less on a "big" program...


Is that posix compliant? how would you deal with a project started that way and with few lines of code, when it grows and then it needs to interact somehow with the surrounding operating system and processes? if you really need something so embedded that you can't afford a main(), you probably don't need a whole operating system below... you should probram the hardware directly...



:) let us know, good luck!!

Ha. Sure. The point about assembler is that you can't trust something that build code for you unless you checked the toolchain from A ot Z. That's the point with LFS (linux from scratch) which rebuild the toolchain from sources. As you can check the source for sanity, you can trust the output.

Crux is source based distro. The toolchain should be recompiled before the kernel. It is maybe a bit insane but for a source based distro, it would be really nice to be reentrant ;)

And for any serious programmer, reading, understanding and writing assembly code is a must have skill. This might sound wrong with Java, python whatever but it helps understanding how a computer work and why those languages are 'slow' against C or well written assembler. After that we enter in the realm of how many usefull line of code you can write per hour... Not much in asm. Let's go for something faster to write : C!



Being counter stream is good. And stripping bloat is good too. Stripping bloat is counter stream? :)

Doing thing with less is good. I was used to Amiga computer : efficient design. They did something reactive with a 7Mhz CPU, 512Kb RAM and hardwired display processor (blitter, copper) more than 20 years ago. And nowdays, when I see how a 400Mhz PowerPC doing a rough 700Mips coupled with a radeon 9250 react badly to user input, I feel a bit depressed.

Developer should work on outdated hardware with slow processor and not much memory. This would help to have efficient code and design that fly everywhere with stripped bloat out of the box.

Hey, I know that's not YOUR toolchain but generic toolchain. For the startup code, 3.5Kb is good with any other kind of program doing more than do nothing and return. I was just a bit worried to eat 3.5Kb for do nothing and return. That's not really do nothing and return. That's do something for 3.5Kb and return. I was just wondering how small I could go for do nothing and return. :) ** This is just an exercice to learn how the thing behave. **

_start is not posix (i guess) compliant but who cares for a simple do nothing and return? And I will not start my progs by _start if I do some clib call elsewhere. I guess the linker will complain anyway.

Hey hardware banging? :) There is a tutorial on powdev about starting the Efika from firmware... No kernel, no services, no drivers, nothing. All the bloat stripped off... :)