Allesandro,
On Thu, Mar 17, 2011 at 8:30 AM, Alessandro Rubini rubini-list@gnudd.com wrote:
It looks like most of your uses are standalone functions that would function just fine on their own. Is there a reason you prefer to have them in a C-file instead of in an assembly file?
Just laziness ;) I'll move these to a new .S file in the next patchset.
Actually, writing assembly-only C functions is difficul and error-pronet. I've seen you use "r0" and other registers esplicitly, but this is not allowed in general.
I once wasted some hours in tracking why a non-submitted port of u-boot was not working with a newer compiler. The problem was just that: the new compiler was inlining a void(void) function; the asm used "r0" and "r1" explicitly, which worked over a function call but was corrupting data when inlined by the newer and more optimizing compiler.
I've moved most of the in-line assembly to lowlevel_init.S. However, the cold_boot() code proved difficult - I got fixup errors, undefined constants, etc. I've cleaned it up a bit, but left it in ap20.c, using the %vars - again, replacing them with the actual values caused errors that I couldn't resolve. Maybe someone else on the list can help to port this code to the assembly file - I'm not expert enough in gcc/as and ARM to do it. New patch to follow RSN.
While your functions are currently not inlined (or, like cold_boot, they may be inlined in a place where no register needs to be preserved), another user may move them to a context where the semantics are different, for another board or another boot loader. If they are in a .S files, they will only be called by "bl" and you know the rules for register allocation appy. Besides, a _real_ lazy programmer avoids the extra quotes and \n in the code :)
/alessandro
Thanks for your insight, Tom