>Ummm, thumb is still 32-bit, right? I know it has 16-bit opcodes, but
>my understanding is that it still supports 32-bit operations. I'm just
>asking if anyone has gone through the trouble of getting some of the
>platform-independant parts of the kernel (i.e. no asm, no asmlinkage)
>to use a thumb backend.
The only real stumbling block here is that the kernel makes fairly heavy use
of embedded assembler via macros defined in <asm/*> header files. Not much of
the kernel is completely untainted by this. Providing Thumb equivalents
should be straightforward. With the right compiler options you might get
away with no other changes to the code; ideally you'd want to add explicit
interworking to the exception handling code.
>I'm very concerned about code footprint and am willing to do some work
>to reduce it; if I can get 30% better code density for the (relatively
>large) networking stack at the expense of some performance, I would
>certainly go for it.
You could try building with -Os as a first step. I don't know how much that
will buy you but it's a lot easier. :-)
>Someone please tell me know if I am grossly misinterpreting the Thumb
>stuff and making a fool of myself...
No, you are on the right track.
>Yeah, I've played with newlib, and it seems pretty nice. My main concern
>is whether it has decent API coverage for a "typical" Linux app (assuming
>it doesn't use lots of GNU or BSD extensions). I guess there's only one
>way to find out...
Newlib doesn't have the appropriate system call glue for Linux at the moment
(or didn't last time I looked, anyhow). I have some half-baked patches to add
it if you decide to go down this path.
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
