Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Deep Toaster on June 29, 2010, 02:25:38 am
-
Okay, so I understand now that compiled ASM programs start with token $BB6D, which is generally copied to address $9D95 for execution (of the program ;)). But what if .org is followed by some other number, like $8000? How does the calculator know where to copy the program?
EDIT: In other words, where does the assembler store the .org number? I tried different .org's in the OTBP assembler, but they all seem to do the same thing.
-
.org works by telling the compiler what to do with JPs/Calls/LD x,()s
basically, the compiler goes through and totals up the bytes, and adds them to the .org. Say that you have this:
.org 1337
jp Label
.db 1,2,3,4,5
label:
ret
the compiler looks at that and says "Ok, Label is 8 bytes after the .org statement, therefore label is located at 1345" and substitutes 1345 with Label. Does that make sense (btw, wasn't sure if jp was a 1 2 or 3 byte command)
-
The ORG number isn't stored anywhere :) Let me explain:
The calculator ALWAYS copies programs to $9d95, no matter what the program is. The org number is just a way for the assembler to resolve labels. The assembler always knows the 'distance in bytes' from a label to the beginning of the program, then it adds the .org number, and you get the actual address in memory. This org number must obviously be $9d95, because that is where the program is run.
On other platforms, you would have other org numbers, etc. Even within 84+ asm coding there are differences: an application has the ORG number $4000. (it doesn't even start executing there, but w/ever)
If you want to experiment, try the following:
- Get SPASM
- Have it compile a simple program, and use the -T option to make it dump a code listing (.lst file)
- Back up the .lst
- Remove the .org from the original .z80 file, and recompile, again with -T
- Compare this listing with the old, back-up listing and look at the addresses in front of each line.
EDIT: Odamn player you ninja'd me
-
Oh :o So the program itself isn't copied to a different location, but all the jumps and calls are sent to locations relative to the .org as if the program were there?
-
mhmm, that's correct. Also @mapar :P mine didn't have a way to experiment, nice
-
No, no. The program is copied, but the labels need the correct values, or otherwise the program goes havoc.
Say I call label1 in 2 different situations:
.org 0 ;just for clarity
blablablabla
call label1
blablabla
label1: ;say this is the 250th byte of the program
blabla
ret
The code would resolve to call 250.
Situation 2:
.org $9d95
bla
blablablabla
call label1
blablabla
label1: ;say this is the 250th byte of the program
blabla
ret
The call instruction would now become call 250+$9d95 (too lazy to convert the hex :D), but it would still be at the same position relative to the beginning of the program.
Is this clear enough? It's really much simpler in concept than it is in words...
EDIT: seeing player's post: I'll summarize: The label resolution is always relative to the program origin. The absolute position therefore is the position relative to the origin+the value of the origin. (that's where .org stands for, btw)
-
:) good explanation
-
Oh, I get it, thanks!
No, no. The program is copied, but the labels need the correct values, or otherwise the program goes havoc.
So technically, I could do a .org at something like $9D94, then shift all the labels accordingly? (I don't see any rational reason for doing this, but who knows...)
By the way, the TI-83 Plus copies to $9D93, right?
EDIT: seeing player's post: I'll summarize: The label resolution is always relative to the program origin. The absolute position therefore is the position relative to the origin+the value of the origin. (that's where .org stands for, btw)
Oh, origin! I thought it was organize or something like that (i.e., organize the program at this address). Origin makes more sense :) Thanks.
-
No. :) Both copy to $9d95. We write .org $9d93 because of the .db $BB,$6D bytes, which should not be counted in. These are equivalent:
.org $9d93
.db $bb,$6d
blablabla
.db $bb,$6d
.org $9d95
blablabla
And I don't quite get what you mean by shifting labels. If you mean inserting one byte so that all labels are shifted one position 'upwards', then yes.
-
Wait, so where you place the .org statement affects its value and hence the values of all relative addressing? Why would this be? Wouldn't it be easier for any assembler to just treat it as the zero point?
-
Where you place the statement has no influence for its value, but it does for the values that follow it. It actually just resets the program counter to the given value in most assemblers.
In one of the first lessons of Assembly in 28 days this concept is explained. I am sure I can't do any better than sigma.
-
Oh. So, THAT'S what .org does. o.o
-
Where you place the statement has no influence for its value, but it does for the values that follow it. It actually just resets the program counter to the given value in most assemblers.
In one of the first lessons of Assembly in 28 days this concept is explained. I am sure I can't do any better than sigma.
Oh, got it. Thanks.
I didn't really understand that lesson in 28D.
What's Sigma?
-
Sigma (or sgm) is Sean McLaughlin's nickname on UTI. He is the author of the 83pa28d tutorial I was referencing.
-
Oh, I see.
-
You might be interested in reading my 5th ASM lesson for more information.
http://ourl.ca/4673/88522
Just note that .org 40339 is the same as .org $9D93. .org $9D95 and .org $9D93 can be interchanged with a few simple changes.
-
Ahaha. I came late to this party! So, to add my $0.02...
You'd usually do the following:.org $9D93
.dw $6DBBinstead of .dw $6DBB
.org $9D95Now, it *shouldn't* make any difference between which one you use, but it does depend on your assembler and what you're trying to make that assembler do. For example, with TASM, your batch files might be assembling your files with the -b or -c switches, which causes all undefined values between known locations to be written out. Which is to say, if you did the latter code, TASM would try to fill in *all* the information between addresses $0000 to $9D95, resulting in a program that's nearly 40KB.
I made this mistake a while back and I'd rather not see it happen again. I don't know how much better the new fancy assemblers like SPASM and Brass and ZDS are, but if this problem hasn't been mentioned, they've gotta be a bit better.
-
I tried this with spasm a while ago iirc, and it didn't make any difference.
-
No. :) Both copy to $9d95. We write .org $9d93 because of the .db $BB,$6D bytes, which should not be counted in. These are equivalent:
.org $9d93
.db $bb,$6d
blablabla
.db $bb,$6d
.org $9d95
blablabla
And I don't quite get what you mean by shifting labels. If you mean inserting one byte so that all labels are shifted one position 'upwards', then yes.
Thanks for clarifying this. It make even more sense to me now. :) Thanks! ;D
-
Thanks :)