On Mon, Jul 10, 2006 at 11:52:52AM +1000, Ian Wienand wrote: > On Sat, Jul 08, 2006 at 03:43:56AM +0000, Horms wrote: > > Can anyone here recomend a good resource to learn ia64 assembly. > > A god book is "Itanium architecture for programmers" by Evans and > Trimper. But that book is really about optimising code, e.g. getting > every last cycle out of a modulo scheduled loop. It is still > worthwhile, however. > > > Basically, I want to change relocate_new_kernel so that it takes its > > physical address as an argument rather than deriving it from the ip. > > This is because I want to run the code in the xen hypervisor, where the > > virtual->physical mapping is different (mask the top 4 bits instead of > > 3), so its more convenient to rely on __pa() in the calling C code. > > Well, I don't know much about Xen or kexec, but looking at the code > example I think it would be less clear to passing to > relocate_new_kernel it's physical address because clearly it can > derive it quite easily. You can use __pa() in assembly anyway, where > it is just x - PAGE_OFFSET, otherwise why not just make the dep > instruction a macro, and #ifdef for Xen?
I wasn't aware that you could use __pa() in assembly, and that might well be a better option. Avoiding the #ifdef was certainly a motivation for wanting to move it into C, but it is also an option. We really wanted to code it up and see what it looked like, then make a decision, then we realised we didn't know enough (any) assembly to proceede further. Another motivation to make the function (more) consistent with other architectures (there are all sorts of random deviations in the ia64 implementation and I struggle to find a good reason for many of them). > Also, I'm a big fan of (just about) every single line of assembly > having a comment. IMHO nothing is obvious when writing in ASM. I will keep that in mind, it is certainly much less than obvious to me. > > I got as far as passing an additional argument in, but any > > modifications I make to relocate_new_kernel beyond that cause it to > > stop functioning :( > > The SKI simulator is your best friend here; it really is the only way > step through so you can find out what you borked. It would be easy to > make a disk image with kexec tools on it; you can then set a > breakpoint and walk through what is happening. Thanks for reminding me about ski. I was thinking of writing some small assembly routines in user-space, just to familiarise myself with what is going on. Ski would be a good way to poke around with them. I've always found that running kernels in ski is painfully slow, but I guess if I have a real problem then its the only way to go. > If you want more > details a good place we can disucss it is on > [EMAIL PROTECTED] Thanks, I'll get myself involve there. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ _______________________________________________ coders mailing list [email protected] http://lists.slug.org.au/listinfo/coders
