Sub-routine Structure
Sub-routine Structure
I have a couple questions about the structure of many sub-routines. Sorry if these are simple questions, but I don't have a programmer background and I just want to make sense of mitsubishi code structure.
SUB400 and SUB41E
Sub400 happens at the first of most sub-routines and Sub41E happens at the end. What do these two subs do and what is the variable these two subs are operating on?
Second, at the begin of the sub you have something like the following:
sts.l pr, @-r15
mov.l r14, @-r15
and at the end
mov.l @+r15, r14
lds.l @+15, pr
Is this "the stack" as I've heard it called?
If I have understood it correctly, pr is carrying the step that the processor is at and r15 carries some floating memory position? This allows the registers that will be used in that sub to be temporarily cleared out and stored in the floating memory and then the last part returns the registers to their initial state and sets the processor back to the step is was previously on?
SUB400 and SUB41E
Sub400 happens at the first of most sub-routines and Sub41E happens at the end. What do these two subs do and what is the variable these two subs are operating on?
Second, at the begin of the sub you have something like the following:
sts.l pr, @-r15
mov.l r14, @-r15
and at the end
mov.l @+r15, r14
lds.l @+15, pr
Is this "the stack" as I've heard it called?
If I have understood it correctly, pr is carrying the step that the processor is at and r15 carries some floating memory position? This allows the registers that will be used in that sub to be temporarily cleared out and stored in the floating memory and then the last part returns the registers to their initial state and sets the processor back to the step is was previously on?
Thanks
I have been comparing your notes from some threads to the ECU code and even with your notes some of this still doesn't make sense and it blows my mind how you and others figured out so much of it.
Maybe I should stick to mechanical stuff...
I have been comparing your notes from some threads to the ECU code and even with your notes some of this still doesn't make sense and it blows my mind how you and others figured out so much of it.
Maybe I should stick to mechanical stuff...
That being said, one way you can approach this is to get a basic understanding of programming concepts and then basic assembly. The combination of those two will help you to figure this out way faster. Maybe the folks here can recommend some books/sites that will help you pick it up better.
If I have understood it correctly, pr is carrying the step that the processor is at and r15 carries some floating memory position? This allows the registers that will be used in that sub to be temporarily cleared out and stored in the floating memory and then the last part returns the registers to their initial state and sets the processor back to the step is was previously on?
PR is simply the procedure register, the return address of any called subroutine is stored here. Simply put when you call a sub routine the address it was called from is stored there.
Essentially if you call another subroutine within the subroutine we are in currently the PR register would get "lost" so we save it in a place of memory which happens to be in this case denoted by subtracting long from @r15.
It seems commonly r14 is used so it is also saved in the same manner with a first subtraction of the already long subtracted r15 value and then stored in that address space.
Subsequently after the routine runs its course they are restored
.Bold summary:
-Store the return address of the sub routine call so its not lost in other calls in the current routine
- Retrieve the PR whatever other registers you wanted restored in the same manner after the routine to complete the sub routine call
Roadspike, it seems my thought pattern is online with what you are saying, just worded by a programming idiot/simpleton such as myself.
I know some basic programming structure, but it's pretty limited. If I choose to go to school for a third degree, it will probably be in computer science as I find this stuff pretty interesting.
I appreciate the help. JCSBanks, when you say it turns off and on an interrupt, does that just mean it basically sets a priority level on running that particular sub-routine?
I know some basic programming structure, but it's pretty limited. If I choose to go to school for a third degree, it will probably be in computer science as I find this stuff pretty interesting.
I appreciate the help. JCSBanks, when you say it turns off and on an interrupt, does that just mean it basically sets a priority level on running that particular sub-routine?
Last edited by 03whitegsr; Jun 22, 2010 at 07:53 AM.
Yes, effectively. Since interrupts are disabled at the beginning of the routine, and re-enabled at the end of the routine, nothing is able to interrupt the current routine from running. Normally to be used very sparingly and for a limited number of instructions for critical areas of hard real-time code only, since you don't want to block any other critical hard real-time code from running for any extended period of time.
Trending Topics
Roadspike, it seems my thought pattern is online with what you are saying, just worded by a programming idiot/simpleton such as myself.
I know some basic programming structure, but it's pretty limited. If I choose to go to school for a third degree, it will probably be in computer science as I find this stuff pretty interesting.
I appreciate the help. JCSBanks, when you say it turns off and on an interrupt, does that just mean it basically sets a priority level on running that particular sub-routine?
I know some basic programming structure, but it's pretty limited. If I choose to go to school for a third degree, it will probably be in computer science as I find this stuff pretty interesting.
I appreciate the help. JCSBanks, when you say it turns off and on an interrupt, does that just mean it basically sets a priority level on running that particular sub-routine?
Pretty strange behavior agreed.
SR being the system register is flagged to set all the repeat counter bits to 1 so maximum repeat counter set. All other bits left alone. The original is then stored in ram and later retrieved back and SR is restored to its original.
That is unless the bits are reverse order, i'm not really sure in this matter
.If it was reversed because of the cpu's indian I would set a whole load of flags to 1. This scenario doesn't make sense to me so i'm going to say its not happening.
Read the SH2 software manual and the SH7054/5 hardware manuals.
r15 is the stack pointer. The - before it reduces the value of r15, and then writes the value to the new address pointed to by r15. The + after r15 reads the value from the address pointed to by r15 and then increases the value of r15. It is a classic LIFO stack.
SR is written carefully following instructions in the hardware manual. You usually read, modify, write these registers. The modify stage usually involves a logical AND or a logical OR with a constant.
r15 is the stack pointer. The - before it reduces the value of r15, and then writes the value to the new address pointed to by r15. The + after r15 reads the value from the address pointed to by r15 and then increases the value of r15. It is a classic LIFO stack.
SR is written carefully following instructions in the hardware manual. You usually read, modify, write these registers. The modify stage usually involves a logical AND or a logical OR with a constant.
Read the SH2 software manual and the SH7054/5 hardware manuals.
r15 is the stack pointer. The - before it reduces the value of r15, and then writes the value to the new address pointed to by r15. The + after r15 reads the value from the address pointed to by r15 and then increases the value of r15. It is a classic LIFO stack.
SR is written carefully following instructions in the hardware manual. You usually read, modify, write these registers. The modify stage usually involves a logical AND or a logical OR with a constant.
r15 is the stack pointer. The - before it reduces the value of r15, and then writes the value to the new address pointed to by r15. The + after r15 reads the value from the address pointed to by r15 and then increases the value of r15. It is a classic LIFO stack.
SR is written carefully following instructions in the hardware manual. You usually read, modify, write these registers. The modify stage usually involves a logical AND or a logical OR with a constant.
.It definitely is using a OR constant in sub400 0xF0 in this case. Since its only effecting bits 32-16 I think its only modifying the RC register with all 1's. It pops the stack later and retrieves the original SR value later.
Haha
At like 1400 pages I've read a bunch of it and a lot of it cruises right over the top of my head. I thought asking for some help wasn't really a bad thing. I figured a few other people wouldn't mind understanding what was happening either.
Socalrally, thanks and that makes a lot of sense. A lot of the code I'm looking at right now is the IPW stuff that is CAS interrupt driven so it makes sense for it to be code that you don't want interrupted at all while it is running.
At like 1400 pages I've read a bunch of it and a lot of it cruises right over the top of my head. I thought asking for some help wasn't really a bad thing. I figured a few other people wouldn't mind understanding what was happening either.
Socalrally, thanks and that makes a lot of sense. A lot of the code I'm looking at right now is the IPW stuff that is CAS interrupt driven so it makes sense for it to be code that you don't want interrupted at all while it is running.
CAS interrupt, that gives me a headache. Don't start with that stuff!
No objection at all to you asking for help, that is what forums are for. I'm sorry that these days (for reason below, time and that I'm not on the Evo platform anymore) I can't contribute like I did. The hardware manuals are really good though. But it helps to already understand assembly language and understand microcontroller hardware. I'd think with about 100 hours of study you could master the SH hardware manual. With my previous experience and the time I've put into the Evo and GTR I've probably put 200 hours into just reading SH2 literature. I spent about 100 hours going through every line of the DSM disassembly. These things take a major investment in time to get good at and get to the point where you can patch an ECU that will die and disable your car if you make a coding mistake and crash the ECU and be happy about doing it.
When I started on the Evo I hadn't done any disassembly before, but I had played with Atmel AVR 8 bit microcontrollers (coded in BASIC!) and back in the day some 6502 and 68k assembly language. The most complex thing I wrote in 68k was a Mandelbrot set plotter though, less than 100 lines of code.
It just takes lots of time, lots of practice, lots of reading. I do not have a single computer qualification whatsoever, end of high school was Maths/Physics/Chemistry and University was medicine. I started as a hobbyist.
I now work half my time for Cobb on the GTR, I like this stuff (and it has gone well enough) that I have reduced my hours in medical practice so I do half on each.
No objection at all to you asking for help, that is what forums are for. I'm sorry that these days (for reason below, time and that I'm not on the Evo platform anymore) I can't contribute like I did. The hardware manuals are really good though. But it helps to already understand assembly language and understand microcontroller hardware. I'd think with about 100 hours of study you could master the SH hardware manual. With my previous experience and the time I've put into the Evo and GTR I've probably put 200 hours into just reading SH2 literature. I spent about 100 hours going through every line of the DSM disassembly. These things take a major investment in time to get good at and get to the point where you can patch an ECU that will die and disable your car if you make a coding mistake and crash the ECU and be happy about doing it.
When I started on the Evo I hadn't done any disassembly before, but I had played with Atmel AVR 8 bit microcontrollers (coded in BASIC!) and back in the day some 6502 and 68k assembly language. The most complex thing I wrote in 68k was a Mandelbrot set plotter though, less than 100 lines of code.
It just takes lots of time, lots of practice, lots of reading. I do not have a single computer qualification whatsoever, end of high school was Maths/Physics/Chemistry and University was medicine. I started as a hobbyist.
I now work half my time for Cobb on the GTR, I like this stuff (and it has gone well enough) that I have reduced my hours in medical practice so I do half on each.
Last edited by jcsbanks; Jun 22, 2010 at 01:24 PM.
Wow, I mean no offense to your social personality but I honestly figured you were some code master that has been locked in the basement of Intel or AMD much of his life based on your work on the ECU. 
Thanks for going over a little of your background, it gives me some hope that someday I may be able to break down a processor on my own without following other people's notes.
This the first time I've ever looked at assembly code and my programming background is limited to Matlab for school projects. Even Matlab I had to self teach as the CS classes I took were in some BS teaching language that isn't used ANY WHERE and likely didn't teach much about basic coding structure.
The CAS interrupt stuff has been 80% following your thread and MRFred's Advanced Fuel Control thread. The other 19% is still stuff I don't understand.

Thanks for going over a little of your background, it gives me some hope that someday I may be able to break down a processor on my own without following other people's notes.
This the first time I've ever looked at assembly code and my programming background is limited to Matlab for school projects. Even Matlab I had to self teach as the CS classes I took were in some BS teaching language that isn't used ANY WHERE and likely didn't teach much about basic coding structure.
The CAS interrupt stuff has been 80% following your thread and MRFred's Advanced Fuel Control thread. The other 19% is still stuff I don't understand.
Btw i didn't see it setting any of the interrupt bits in the SR register with 400 and 41e in an evo 8 rom.
The routines set all the interrupt mask bits, storing the old value on a mini stack, with the other routine restoring them. It really isn't exciting. Look at it once, then forget it, it is a black box.







