JSR problem - what am I doing wrong

[+Stephen Moss]

HI folks,

I am having a little problem with some test code I am writing and I hope someone will know the answer.

 

Basically my program has three sections and in a departure from my previous programs I am splitting each section into its own file but each of them has to perform a JSR to a delay subroutine which is in a fourth file.

It all seems to compile and link ok with SMAC and ALN and it runs up to point of the first JSR call at which point there is a slight delay (probably the duration of delay subroutine) and then instead of proceeding with the rest of the program it appears to return to the _start: label.

I know the delay subroutine works as I have used it before in single file programs but I know the problem is connect somehow as when I comment out all the JSR lines the rst of the program is executed.

 

;######################

;# Delay_Count Subroutine #

;######################

Delay_Count:: ; Delay_Count Subroutine (Global Label)

 

move.w #$FFFF, D7 ; Move Delay_Count Count into register D7

Delay:

nop ; Do nothing

sub #$0001, D7 ; Subrtact 1 from Delay_Count loop count

bne Delay ; Loop if count has not reached 0

 

RTS ; Return

 

As you can see my delay is just a simple loop, I have tried referencing Delay_Count label as both .extern and .globl in the files that call it but still no joy. What am I missing?

[ggn]

It's a bit hard to say what happens without looking at the rest of the source, but here's a couple of ideas:

 

a) Why are you using smac and aln? I'm not sure if mixing assemblers and linkers is a good idea, try sln maybe?

b) try saving/restoring d7 (move.l d7,-(sp) / movem.l (sp)+,d7) in the beginning and end of the subroutine. Perhaps d7 is needed by your main code somewhere.

c) .globl and .extern imply that your sources are independent and only reference each other at link time. IIRC we encountered some problems when we did that, so traditionally all Reboot's Jaguar programs don't do that. Instead the main file INCLUDEs all the rest and this is the only file mac/smac parses.

 

Hope this helps.

Edited August 7, 2011 by ggn

[+CyranoJ]

I'd go with INCLUDE instead of linking. It makes things much easier to manage and has no real disadvantage compared to linking (unless your the kind of masochist who likes .globl and .extern!) as your source files can still be split into modules.

[Matthias]

It all seems to compile and link ok with SMAC and ALN and it runs up to point of the first JSR call at which point there is a slight delay (probably the duration of delay subroutine) and then instead of proceeding with the rest of the program it appears to return to the _start: label.

 

I am not sure why the above described could happen, but here is what i have spotted:

 

I know the delay subroutine works as I have used it before in single file programs but I know the problem is connect somehow as when I comment out all the JSR lines the rst of the program is executed.

 

;######################

;# Delay_Count Subroutine #

;######################

Delay_Count:: ; Delay_Count Subroutine (Global Label)

 

move.w #$FFFF, D7 ; Move Delay_Count Count into register D7

Delay:

nop ; Do nothing

sub #$0001, D7 ; Subrtact 1 from Delay_Count loop count

bne Delay ; Loop if count has not reached 0

 

RTS ; Return

 

The 68000 is used as 32bit processor, so LONG is the preffered data-size and assemblers will use it if you don't tell better it in each of your code-line.

 

You seem to want to use register D7 as a WORD-counter, but later you use SUB without a data-size instruction, so the #$0001 will be substracted from the 32bit-number stored in d7 (you only filled the lower WORD of d7 with $ffff) and the BNE will react on this LONG-word calculation.

 

Solution: Either use

move.l #$ffff,d7

or

sub.w #$1,d7

 

 

And make sure that d7 isn't changed by the interrupt-handlers.

 

Kind regards

Matthias

[Zerosquare]

The 68000 is used as 32bit processor, so LONG is the preffered data-size and assemblers will use it if you don't tell better it in each of your code-line.

Are you sure about that? I thought the default size was Word (.w), not Long (.l). I'm not 100% sure because I always write the size explicitely, and I couldn't find any info on it in Madmac's documentation.

 

To Stephen : check that the stack pointer has been initialized correctly, and that nothing in your code writes on the stack or corrupts it (e.g., unpaired movem instructions, etc.)

[+Stephen Moss]

Thanks all I will try you suggestions when I have time.

Edited August 9, 2011 by Stephen Moss

[LinkoVitch]

Just from another point... (and speaking as a masochist that likes linking )

 

I have found that the order of the object files you pass to ALN can matter. So have you made sure the 1st object file is your main code that should run 1st and the delay loop runs after that?

 

Unrelated to your problem but I would possibly write your delay loop as:

 

move.w #$ffff,d7

 

.loop:

nop

dbra.w d7,.loop ; decrement d7 by 1 and branch to the label whilst d7 is positive

 

rts

 

 

 

you could remove the nop if you weren't using it to lengthen the delay any to make it a very short piece of code.

 

I'd also say be as specific in your code as you can, so make sure you put .b, .w and .l on anything that can to be 100% certain what the instruction will be using as its data.

 

Anything else has already been mentioned. hope you get it working.

[+Stephen Moss]

a) Why are you using smac and aln? I'm not sure if mixing assemblers and linkers is a good idea, try sln maybe?

I try using SLN but I always get the following error message and it fails to produce a COF file.

dosym<> : Cannot get object file segment size : startup.o

 

Just from another point... (and speaking as a masochist that likes linking )

 

I have found that the order of the object files you pass to ALN can matter. So have you made sure the 1st object file is your main code that should run 1st and the delay loop runs after that?

I was aware of that, thanks. I found that out when using the SkunkConsole, the Skunklib file has to go before those that reference it otherwise you get errors caused by the linker not knowing where the lable to jump to is not having previously passed the Skunklib file.

 

Anything else has already been mentioned. hope you get it working.

Well I have gone back to a single file which I now have working (Dual Shock motor speed varies with stick position) so I will try dissemminating it into seperate files and see how I get on form there.

[rush6432]

wait:

move.l #400,d1

moveq #0,d0

.waitloop:

addq #1,d0

nop

cmp.l d1,d0

bne .waitloop

rts

 

Little function that should do what you want...

 

Of course you can always define a variable or two to use instead of a register(s) to compare against as well, just make sure to define them properly as a word, long or byte (which ever way they are being used)

 

As for the linking, make sure to link the main object file first. You would link this object file first and then if after the startup code has run and transfers to the main file with your code, you would like this file next.

 

Just remember that the jag processes all things from top to bottom as they are linked per say. If your video and system initialization is first (which it should be) then have this the first file linked and then have it jump to either another file containing all other code or keep it all within the same file if you would like.

Edited August 17, 2011 by rush6432

[Tyrant]

I'd go with INCLUDE instead of linking. It makes things much easier to manage and has no real disadvantage compared to linking (unless your the kind of masochist who likes .globl and .extern!) as your source files can still be split into modules.

*raises hand*

 

I'm that kind of masochist (when it comes to code anyway). I like the way my .globl's and .externs make it explicit what goes in and out of which files, and I make each source file into exactly one object file with atari's original mac and aln... although I do use a much newer version of make to bind it all together for me. I don't even use the shortcuts to global things like the double colon, but I do sometimes make .inc files if I've got a load of .externs to put in most of my files, or for constants that affect many files.

[LinkoVitch]

 

I'm that kind of masochist (when it comes to code anyway). I like the way my .globl's and .externs make it explicit what goes in and out of which files, and I make each source file into exactly one object file with atari's original mac and aln... although I do use a much newer version of make to bind it all together for me. I don't even use the shortcuts to global things like the double colon, but I do sometimes make .inc files if I've got a load of .externs to put in most of my files, or for constants that affect many files.

 

I tend to create .h header files for my code that has the .EXTERNs in for labels that need to be accessed external to that code file. Anything that needs to access that then includes the appropriate headers. Not exactly the simplest I know but its how my brain 'works'

[Tyrant]

I guess that makes sense if you do a lot of C/C++ work normally. Habits carry over easily, which is why I wrote a bit of C a while ago with a handful of generic int's called d0 - d7 .

[LinkoVitch]

I guess that makes sense if you do a lot of C/C++ work normally. Habits carry over easily, which is why I wrote a bit of C a while ago with a handful of generic int's called d0 - d7 .

 

That's exactly where I get it from

 

I haven't done that, but I did write some C which ended up with an equation essentially ending up like

 

f=a+b;

e=c+d;

b=f*e;

 

Until I remembered this is a high-level language and slapped it all into a single equation

[+CyranoJ]

I try using SLN but I always get the following error message and it fails to produce a COF file.

dosym<> : Cannot get object file segment size : startup.o

 

I just got this and spent a few hours trying to work it out. It seems SLN can't open any .o files in sub directories. Copy all the .o files to one place and it links them fine. I've mailed subQmod about this, hopefully he can fix it in a new version

[GT Turbo]

The 68000 is used as 32bit processor, so LONG is the preffered data-size and assemblers will use it if you don't tell better it in each of your code-line.

Are you sure about that? I thought the default size was Word (.w), not Long (.l). I'm not 100% sure because I always write the size explicitely, and I couldn't find any info on it in Madmac's documentation.

 

 

word is the size by default for 68000 assemblers.

 

 

GT