To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcxOpen lugnet.robotics.rcx in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / 1199
    H8/300 Assembler/C interface —Ralph Hempel
   Does anyone know offhand what the calling convention between C/C++ and H8/300 assembler is using the GNU tools? The assumptions I'm making are as follows: R7 is the stack pointer R6 is the first (leftmost) parameter passed and the result R0-5 are (...) (23 years ago, 18-Apr-01, to lugnet.robotics.rcx)
   
        Re: H8/300 Assembler/C interface —Kekoa Proudfoot
     (...) Somebody correct me if I'm wrong. I just compiled some programs to check this. I believe that maybe the *ROM* calling convection is as Ralph described, but almost definitely the GCC calling convention is: - r0, r1, r2 hold parameters from left (...) (23 years ago, 18-Apr-01, to lugnet.robotics.rcx)
    
         Re: H8/300 Assembler/C interface —Kekoa Proudfoot
      (...) Also: - caller cleans up parameters on stack - stack pointer is r7 The caller must clean up stack parameters b/c the return address is pushed after parameters are. -Kekoa (23 years ago, 18-Apr-01, to lugnet.robotics.rcx)
     
          RE: H8/300 Assembler/C interface —Ralph Hempel
       (...) Not necessarily, that's why I'm asking. If the caller cleans up the stack, then the function just does an RTS and the caller adjusts the stack because it knows how much stuff was pushed on. For programs with lots of calls, this generates extra (...) (23 years ago, 19-Apr-01, to lugnet.robotics.rcx)
      
           Re: H8/300 Assembler/C interface —Kekoa Proudfoot
       (...) Yeah, you are right. My bad. -Kekoa (23 years ago, 19-Apr-01, to lugnet.robotics.rcx)
     
          RE: H8/300 Assembler/C interface —Ralph Hempel
      (...) I've just done some more browsing and found this tidbit: (URL) It seems to indicate that tghe registers are always filled and that a long may be split across r2 and the stack. Comments? Cheers, Ralph (23 years ago, 20-Apr-01, to lugnet.robotics.rcx)
     
          Re: H8/300 Assembler/C interface —Kekoa Proudfoot
      (...) I wrote C code and then disassembled it. :) -Kekoa (23 years ago, 20-Apr-01, to lugnet.robotics.rcx)
     
          Re: H8/300 Assembler/C interface —Kekoa Proudfoot
      (...) To be more specific, I wrote C code, then disassembled it. The C types "long" and "float" are both split. -Kekoa (23 years ago, 20-Apr-01, to lugnet.robotics.rcx)
     
          RE: H8/300 Assembler/C interface —Ralph Hempel
      (...) Not to be too obtuse, but your first message says that long and float are never split across r2 and stack. So you're saying that they ARE split? That's fine, because it makes things a lot easier - not that any of my functions actually need to (...) (23 years ago, 20-Apr-01, to lugnet.robotics.rcx)
     
          Re: H8/300 Assembler/C interface —Kekoa Proudfoot
      (...) No no no! Sorry. They are NOT split. Boy am I dumb. -Kekoa (23 years ago, 20-Apr-01, to lugnet.robotics.rcx)
     
          Re: H8/300 Assembler/C interface —Björn Lundin
      (...) By looking at your work with 'RCX internals', dumb is not the word i'd use :) I'd rather think of something like 'bit wizard' Björn (23 years ago, 21-Apr-01, to lugnet.robotics.rcx)
    
         RE: H8/300 Assembler/C interface —Ralph Hempel
     (...) Thanks Kekoa. One more question, are the other registers r3,r4,r5,r6 considered volatile across a function call in GCC? Cheers, Ralph (23 years ago, 19-Apr-01, to lugnet.robotics.rcx)
    
         Re: H8/300 Assembler/C interface —Kekoa Proudfoot
     (...) By the caller? No. They are callee-save. -Kekoa (23 years ago, 19-Apr-01, to lugnet.robotics.rcx)
    
         RE: H8/300 Assembler/C interface —Ralph Hempel
     (...) Ahhh, that makes it awkward with the RCX ROM calls, but I'm pretty sure I can make my assembler source compatible with this. I'm just getting ready to release an assembler RCX serial library that is either polled or interrupt driven. Any (...) (23 years ago, 19-Apr-01, to lugnet.robotics.rcx)
   
        RE: H8/300 Assembler/C interface —Ralph Hempel
   One more question for Kekoa before I'm done... The RCX ROM routines take a parameter in r6, with additional params on the stack. Return value is in r6 too. Are all other registers considered volatile through the call, or do the ROM routines save (...) (23 years ago, 20-Apr-01, to lugnet.robotics.rcx)
   
        Re: H8/300 Assembler/C interface —Kekoa Proudfoot
   (...) A brief review of the ROM disassembly seems to indicate the routines in ROM save r0-r5 if necessary. For example, the routine at 070c saves all registers. Like you said, parameters are passed in r6 with extra parameters on the stack. The (...) (23 years ago, 20-Apr-01, to lugnet.robotics.rcx)
   
        RE: H8/300 Assembler/C interface —Ralph Hempel
   (...) Geez Kekoa, get some sleep. The GCC makes the callee clean up the stack. My pbForth ROM interface routines assume that the caller cleans up the stack, just like your RCX library which must have been confusing for you :-) I'll post all this in (...) (23 years ago, 21-Apr-01, to lugnet.robotics.rcx)
   
        Re: H8/300 Assembler/C interface —Kekoa Proudfoot
   (...) Not my GCC: 00000016 <_main>: 16: 6d f6 mov.w r6,@-e7 <-- save frame pointer 18: 0d 76 mov.w r7,r6 <-- new frame pointer 1a: 6b 00 00 00 mov.w @0x0:16,r0 <-- r0r1 is 1st long param 1e: 6b 01 00 00 mov.w @0x0:16,r1 22: 6b 02 00 00 mov.w (...) (23 years ago, 21-Apr-01, to lugnet.robotics.rcx)
   
        Re: H8/300 Assembler/C interface —John A. Tamplin
     (...) -fomit-frame-pointer, but it can cause problems debugging (obviously not important here). John A. Tamplin jat@jaet.org 770/436-5387 HOME 4116 Manson Ave 770/431-9459 FAX Smyrna, GA 30082-3723 (23 years ago, 21-Apr-01, to lugnet.robotics.rcx)
   
        RE: H8/300 Assembler/C interface —Ralph Hempel
   (...) Sorry, looks like I need sleep too! (...) Hmm, looks like r2 is a copy of the high byte of the second long, but the complete long is pushed onto the stack! So the thing about GCC NOT splitting is true, it just keeps a copy of the higher order (...) (23 years ago, 21-Apr-01, to lugnet.robotics.rcx)
 

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR