> >> The second thought is learn the ABI convention for calling C methods > >> from assembly and you can pass whatever data you need to a function > >> that will do the printing for you. I'd suggest going with this route > >> since it will be the most straightforward without soldering but also > >> the least versatile. --You may end up rebooting many, many times and > >> the less overhead there is to initialize before playing around the > >> faster you can try a new idea. At any rate, I believe the ABI changed > >> when we went to the armel format and so there's a handy description on > >> changes to system calls and so forth here: > >> http://wiki.debian.org/ArmEabiPort Sorry if I'm pointing out anything > >> that might be obvious, these are just things I had to work through > >> when I was working on this type of thing on OS-less boards. > >> > > Thanks for that pointer, I'd forgotten about that page. It does say how > > registers are passed (but I think it says to system calls rather than some > > random function). I'll have to look at it again and do some more digging (and in > > the meantime save the value of R14 to an array each time the handler code is > > called, then print it out in C after the asm has completed). > > > That part is talking about normal function calls. So you have 4 > registers to pass arguments, > rest is passed in stack.
The title of that section is "System call interface" and it describes how to load registers with arguments and how to get return values. That's fair enough, thinking about it, printing to stdout will involve a system call that I should be able to generate using this and other information (like a list of system call numbers, so I can work out what to call), but it's still a system call, rather than a call to a C function that I've written (my explanation may not have been clear enough, my apologies). Or have I completely mis-read the page? What I was really after was a way of calling a C function from within some inline asm. I was wondering whether the assembler was able to provide a way of jumping to C functions written in the same source file as the asm() itself? I suppose there may be a system call that will take a function name as an argument and call that, this would work for library functions and probably for functions in the same source file. I need to do some Googling. This has got me thinking, what happens when the end of a piece of inline asm is reached? Do I need to always jump to a label I've placed at the end of the inline asm, or is there a way to return to the C code from in the middle of the asm. Another one: can I know the address of a piece of asm (within the asm or surrounding C code)? So that I could jump from one piece to another? This is probably trying to use inline asm for things it's not designed for, I suppose I may be better writing a function in asm and putting it in a .S file and calling that from the C code. Again Google here I come. > > Does anyone know whether there are there any good docs/books on ARM asm > > programming, telling people these sort of things? This is an interesting (and > > hopefully useful) learning experience, but can be really frustrating when I know > > what I want to do, and pretty much how to, but not quite! :) E.g. calling > > functions in linked libraries, how to call .s file functions from C, what is and > > isn't allowed in in-line asm, etc. > > > I don't think there is really such a book, but you can use > gcc -S to see what kind of assembler > gcc generates to call functions. Yes, that's a good idea. The only problem I can see is that the function I may want to call has already been converted into asm, with a label denoting the start of the function, rather than being in C. It may be that there is actually no way of branching from inline asm to a C function. This is the kind of thing I'd like a book to be able to tell me (so I don't waste time trying to find out how to do something that's not possible, etc.) On the other hand it will work for calling printf, so I'll take a look at the asm of a "hello world" program. Thanks, Simon _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
