Author Topic: Here's another not-absolutely-necessary question I have, just out of curiosity. (Read 9437 times)

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.

_player1537 · « **Reply #1 on:** June 29, 2010, 02:31:30 am »

.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)

mapar007 · « **Reply #2 on:** June 29, 2010, 02:33:50 am »

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

Deep Toaster · « **Reply #3 on:** June 29, 2010, 02:35:11 am »

Oh

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?

_player1537 · « **Reply #4 on:** June 29, 2010, 02:37:30 am »

mhmm, that's correct. Also @mapar

mine didn't have a way to experiment, nice

mapar007 · « **Reply #5 on:** June 29, 2010, 02:40:26 am »

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:

Code: [Select]

.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:

Code: [Select]

.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

), 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)

_player1537 · « **Reply #6 on:** June 29, 2010, 02:58:13 am »

good explanation

Deep Toaster · « **Reply #7 on:** June 29, 2010, 03:11:41 am »

Oh, I get it, thanks!

Quote from: mapar007 on June 29, 2010, 02:40:26 am

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?

Quote from: mapar007 on June 29, 2010, 02:40:26 am

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.

mapar007 · « **Reply #8 on:** June 29, 2010, 04:39:23 am »

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:

Code: [Select]

.org $9d93
.db $bb,$6d
blablabla

Code: [Select]

.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.

Deep Toaster · « **Reply #9 on:** June 29, 2010, 06:04:48 am »

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?

mapar007 · « **Reply #10 on:** June 29, 2010, 06:19:59 am »

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.

Raylin · « **Reply #11 on:** June 29, 2010, 08:33:17 am »

Oh. So, THAT'S what .org does. o.o

Deep Toaster · « **Reply #12 on:** June 29, 2010, 10:44:54 am »

Quote from: mapar007 on June 29, 2010, 06:19:59 am

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?

mapar007 · « **Reply #13 on:** June 29, 2010, 10:47:52 am »

Sigma (or sgm) is Sean McLaughlin's nickname on UTI. He is the author of the 83pa28d tutorial I was referencing.

Deep Toaster · « **Reply #14 on:** June 29, 2010, 10:49:07 am »

Oh, I see.

Author Topic: Here's another not-absolutely-necessary question I have, just out of curiosity. (Read 9437 times)

Deep Toaster

Here's another not-absolutely-necessary question I have, just out of curiosity.

_player1537

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

mapar007

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

Deep Toaster

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

_player1537

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

mapar007

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

_player1537

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

Deep Toaster

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

mapar007

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

Deep Toaster

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

mapar007

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

Raylin

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

Deep Toaster

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

mapar007

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.

Deep Toaster

Re: Here's another not-absolutely-necessary question I have, just out of curiosity.