Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #2000 > unrolled thread

Secret Shame? Reading Source Code

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Secret Shame? Reading Source Code ultramagnus_tcv <mikew@thecomputervalet.com> - 2015-12-11 10:06 -0600
    Re: Secret Shame? Reading Source Code Chris Torrence <gorthmog@gmail.com> - 2015-12-11 08:50 -0800
      Re: Secret Shame? Reading Source Code ultramagnus_tcv <mikew@thecomputervalet.com> - 2015-12-12 08:38 -0600
        Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2015-12-12 16:04 -0600
          Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2015-12-12 16:10 -0600
          Re: Secret Shame? Reading Source Code ultramagnus_tcv <mikew@thecomputervalet.com> - 2015-12-13 10:21 -0600
            Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2015-12-13 11:23 -0600
              Re: Secret Shame? Reading Source Code ultramagnus_tcv <mikew@thecomputervalet.com> - 2015-12-13 11:41 -0600
            Re: Secret Shame? Reading Source Code dempson@actrix.gen.nz (David Empson) - 2015-12-14 08:15 +1300
              Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2015-12-13 17:16 -0600
              Re: Secret Shame? Reading Source Code Jeff Blakeney <CUTjeffrey_blakeney@yahoo.ca> - 2015-12-13 18:17 -0500
                Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2015-12-13 17:39 -0600
                Re: Secret Shame? Reading Source Code m.omalley.au@gmail.com - 2016-01-24 02:26 -0800
                  Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2016-01-24 10:45 -0600
                    Re: Secret Shame? Reading Source Code wssimms@gmail.com - 2016-01-24 15:20 -0800
                      Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2016-01-24 23:33 -0600
                        Re: Secret Shame? Reading Source Code wssimms@gmail.com - 2016-01-25 05:01 -0800
                          Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2016-01-25 16:29 -0600
      Re: Secret Shame? Reading Source Code michael.pohoreski@gmail.com - 2016-01-27 07:09 -0800
    Re: Secret Shame? Reading Source Code wssimms@gmail.com - 2015-12-11 18:02 -0800
      Re: Secret Shame? Reading Source Code awanderin <awanderin@gmail.com> - 2015-12-11 23:01 -0700
        Re: Secret Shame? Reading Source Code Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-01-28 12:33 -0800
          Re: Secret Shame? Reading Source Code Michael Barry <barrym95838@yahoo.com> - 2016-01-28 22:50 -0800
            Re: Secret Shame? Reading Source Code wssimms@gmail.com - 2016-01-29 02:04 -0800
            Re: Secret Shame? Reading Source Code Michael J. Mahon <mjmahon@aol.com> - 2016-01-29 13:58 -0600
            Re: Secret Shame? Reading Source Code Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-01-29 16:10 -0800
            Re: Secret Shame? Reading Source Code Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-01-29 16:15 -0800
              Re: Secret Shame? Reading Source Code Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2016-01-31 03:50 -0600
    Re: Secret Shame? Reading Source Code michael.pohoreski@gmail.com - 2016-01-25 11:03 -0800
    Re: Secret Shame? Reading Source Code michael.pohoreski@gmail.com - 2016-01-25 11:04 -0800
    Re: Secret Shame? Reading Source Code michael.pohoreski@gmail.com - 2016-01-27 07:14 -0800
      Re: Secret Shame? Reading Source Code ultramagnus_tcv <mikew@thecomputervalet.com> - 2016-04-29 19:33 -0500

Page 1 of 2  [1] 2  Next page →

#2000 — Secret Shame? Reading Source Code

Hey folks,

I come before you humbled by the fact that I have no idea how to read 
source files. Oh, I can read English and I have a passing familiarity 
with 6502 assembly, but I don't understand some (basic?) things about 
it.

I have a few questions and I hoped I could be set straight on:

1. Are the numbers on the left typical of where the program resides in 
memory rather while running than on disk?

2. If there is no accompanying information with the source, how does 
one figure out what assembler was using to write the code? For 
instance, does Apple always use EDASM? (I did most of my studies in 
Merlin.)

3. If one were a masochist, could one enter the hexadecimal values on 
the left into, say, the monitor?

4. I've been told that you can't merely identify the assembler used and 
then re-type the code into that assembler and expect it to assemble 
and/or run. Why would that be?

I apologize if these are dumb questions. As I investigate the Apple 
///, I often find people refer me to the source. But if I can't read 
it.........?

Cheers,

Mike...

[toc] | [next] | [standalone]

#2002

On Friday, December 11, 2015 at 9:06:18 AM UTC-7, ultramagnus_tcv wrote:
> Hey folks,
> 
> I come before you humbled by the fact that I have no idea how to read 
> source files. Oh, I can read English and I have a passing familiarity 
> with 6502 assembly, but I don't understand some (basic?) things about 
> it.
> 
> I have a few questions and I hoped I could be set straight on:
> 
> 1. Are the numbers on the left typical of where the program resides in 
> memory rather while running than on disk?
> 
> 2. If there is no accompanying information with the source, how does 
> one figure out what assembler was using to write the code? For 
> instance, does Apple always use EDASM? (I did most of my studies in 
> Merlin.)
> 
> 3. If one were a masochist, could one enter the hexadecimal values on 
> the left into, say, the monitor?
> 
> 4. I've been told that you can't merely identify the assembler used and 
> then re-type the code into that assembler and expect it to assemble 
> and/or run. Why would that be?
> 
> I apologize if these are dumb questions. As I investigate the Apple 
> ///, I often find people refer me to the source. But if I can't read 
> it.........?
> 
> Cheers,
> 
> Mike...

Hi Mike,

You might take a look at Assembly Lines: The Complete Book: 
http://www.lulu.com/shop/roger-wagner/assembly-lines-the-complete-book/hardcover/product-21959093.html 
http://amzn.com/1312089407

You can also find it for free on the Internet Archive. :-)
Cheers,
Chris

[toc] | [prev] | [next] | [standalone]

#2005

On 2015-12-11 16:50:43 +0000, Chris Torrence said:

> Hi Mike,
> 
> You might take a look at Assembly Lines: The Complete Book:
> http://www.lulu.com/shop/roger-wagner/assembly-lines-the-complete-book/hardcover/product-21959093.html 
> 
> http://amzn.com/1312089407
> 
> You can also find it for free on the Internet Archive. :-)

Hmmm... Your response makes me wonder what I am missing, then. I have 
read Assembly Lines. In fact, I used it to create a program that took 
keyboard input on an Apple II and displayed the key pressed, the binary 
representation, the decimal representation, and the hexadecimal 
representation. It was really basic, but I had to figure out a lot of 
basic stuff that the book was key to help me to do. It took several 
months of going through the book and working through all the exercises. 
It was hugely fun and highly educational.

Having said all that, I read the original Assembly Lines, not your 
updated version (which I purchased some time, back. Thanks!). I know 
there is more material in there than the original book had and I've 
never seen the entire run of Softalk columns. Perhaps there is 
something in there about reading assembly output from other assemblers?

It's also possible that I'm looking at other syntax and then reacting. 
In other words, I see something different and have this visceral, "I 
... I ... I ... don't know what's happening here. Command-Q." I suppose 
I'll never learn anything that way.

Here's an example. This is from the SOS source code (page 13: 
http://apple3.org/Documents/SourceCode/Apple3_SOS_1.3.pdf)

1E08:62 00 158 K.HDR.CNT DW LDR.ADR-K.DRIVES

Breaking this down:

1E08		Memory Address (Equivalent to what I'd see on the left when 
assembling with Merlin?)
62 00		Presumably the opcode and operand. I can't find 62 online. Being 
SOS, the CPU is a 6502A.
158			Line number of the listing
K.HDR.CNT	Dunno. Perhaps a label?
DW			Dunno. I'm guessing Double Word, but I can't seem to find a definition.
LDR.ADR.K.DRIVES
			Another label? It's not referenced anywhere else in the PDF. 
K.DRIVES is, however, which makes me wonder if this isn't some sort of 
command or path. Perhaps K.HDR.CNT is a path or command, too?

Does this help explain my confusion? My gut says I am confused by 
syntax differences between what I learned in Merlin and whatever else 
this particular source was assembled in.

m

[toc] | [prev] | [next] | [standalone]

#2006

ultramagnus_tcv <mikew@thecomputervalet.com> wrote:
> On 2015-12-11 16:50:43 +0000, Chris Torrence said:
> 
>> Hi Mike,
>> 
>> You might take a look at Assembly Lines: The Complete Book:
>> http://www.lulu.com/shop/roger-wagner/assembly-lines-the-complete-book/hardcover/product-21959093.html
>> 
>> 
>> http://amzn.com/1312089407
>> 
>> You can also find it for free on the Internet Archive. :-)
> 
> Hmmm... Your response makes me wonder what I am missing, then. I have 
> read Assembly Lines. In fact, I used it to create a program that took 
> keyboard input on an Apple II and displayed the key pressed, the binary 
> representation, the decimal representation, and the hexadecimal 
> representation. It was really basic, but I had to figure out a lot of 
> basic stuff that the book was key to help me to do. It took several 
> months of going through the book and working through all the exercises. 
> It was hugely fun and highly educational.
> 
> Having said all that, I read the original Assembly Lines, not your 
> updated version (which I purchased some time, back. Thanks!). I know 
> there is more material in there than the original book had and I've 
> never seen the entire run of Softalk columns. Perhaps there is 
> something in there about reading assembly output from other assemblers?
> 
> It's also possible that I'm looking at other syntax and then reacting. 
> In other words, I see something different and have this visceral, "I 
> ... I ... I ... don't know what's happening here. Command-Q." I suppose 
> I'll never learn anything that way.
> 
> Here's an example. This is from the SOS source code (page 13: 
> http://apple3.org/Documents/SourceCode/Apple3_SOS_1.3.pdf)
> 
> 1E08:62 00 158 K.HDR.CNT DW LDR.ADR-K.DRIVES
> 
> Breaking this down:
> 
> 1E08		Memory Address (Equivalent to what I'd see on the left when 
> assembling with Merlin?)
> 62 00		Presumably the opcode and operand. I can't find 62 online. Being 
> SOS, the CPU is a 6502A.
> 158			Line number of the listing
> K.HDR.CNT	Dunno. Perhaps a label?
> DW			Dunno. I'm guessing Double Word, but I can't seem to find a definition.
> LDR.ADR.K.DRIVES
> 			Another label? It's not referenced anywhere else in the PDF. 
> K.DRIVES is, however, which makes me wonder if this isn't some sort of 
> command or path. Perhaps K.HDR.CNT is a path or command, too?
> 
> Does this help explain my confusion? My gut says I am confused by 
> syntax differences between what I learned in Merlin and whatever else 
> this particular source was assembled in.
> 
> m

It's not really so mysterious--take heart!  ;-)

Assemblers mostly differ in fairly trivial ways, such as the mnemonics
chosen for "pseudo ops" that are *not* machine instructions, but
instructions to the assembler to reserve data space, define constants, or
control the listing.  The syntax for describing arithmetic/logical
expressions as operands may also differ, both in operators used (+, -, ^
[exor], etc.) and in complexity of operations permitted. 

In the example you give, the pseudo-op is "dw", which stands, as you
guessed, for "double word"--in this case, a two-byte data item. Its operand
is an expression which is evaluated as a 16-bit quantity by the assembler,
then used as the (initial) value of the two-byte field. In this case, the
value is the value of the symbol LDR.ADR minus the value of the symbol
K.DRIVES, which is apparently $0062. 

The leftmost field of virtually every assembly line is an optional label,
which gets defined as the current value of the location counter, which
corresponds to the address of the first generated byte (if any) for this
line. 

So, for each assembly line:

<optional label>  <op/pseudo-op>  <optional operand expression>  <;
optional comment>

And each listing line is the source line preceded by:

<current location counter> <generated data> <source file line number> 

The <generated data> may be truncated to a few bytes to keep the listing
down to one line per source line, but it's all still there in the object
code file.  (This "unlisted" data is one thing that could lead to incorrect
results if the hex visible in the listing is just typed into the monitor.)
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2007

Michael J. Mahon <mjmahon@aol.com> wrote:
> ultramagnus_tcv <mikew@thecomputervalet.com> wrote:
>> On 2015-12-11 16:50:43 +0000, Chris Torrence said:
>> 
>>> Hi Mike,
>>> 
>>> You might take a look at Assembly Lines: The Complete Book:
>>> http://www.lulu.com/shop/roger-wagner/assembly-lines-the-complete-book/hardcover/product-21959093.html
>>> 
>>> 
>>> http://amzn.com/1312089407
>>> 
>>> You can also find it for free on the Internet Archive. :-)
>> 
>> Hmmm... Your response makes me wonder what I am missing, then. I have 
>> read Assembly Lines. In fact, I used it to create a program that took 
>> keyboard input on an Apple II and displayed the key pressed, the binary 
>> representation, the decimal representation, and the hexadecimal 
>> representation. It was really basic, but I had to figure out a lot of 
>> basic stuff that the book was key to help me to do. It took several 
>> months of going through the book and working through all the exercises. 
>> It was hugely fun and highly educational.
>> 
>> Having said all that, I read the original Assembly Lines, not your 
>> updated version (which I purchased some time, back. Thanks!). I know 
>> there is more material in there than the original book had and I've 
>> never seen the entire run of Softalk columns. Perhaps there is 
>> something in there about reading assembly output from other assemblers?
>> 
>> It's also possible that I'm looking at other syntax and then reacting. 
>> In other words, I see something different and have this visceral, "I 
>> ... I ... I ... don't know what's happening here. Command-Q." I suppose 
>> I'll never learn anything that way.
>> 
>> Here's an example. This is from the SOS source code (page 13: 
>> http://apple3.org/Documents/SourceCode/Apple3_SOS_1.3.pdf)
>> 
>> 1E08:62 00 158 K.HDR.CNT DW LDR.ADR-K.DRIVES
>> 
>> Breaking this down:
>> 
>> 1E08		Memory Address (Equivalent to what I'd see on the left when 
>> assembling with Merlin?)
>> 62 00		Presumably the opcode and operand. I can't find 62 online. Being 
>> SOS, the CPU is a 6502A.
>> 158			Line number of the listing
>> K.HDR.CNT	Dunno. Perhaps a label?
>> DW			Dunno. I'm guessing Double Word, but I can't seem to find a definition.
>> LDR.ADR.K.DRIVES
>> Another label? It's not referenced anywhere else in the PDF. 
>> K.DRIVES is, however, which makes me wonder if this isn't some sort of 
>> command or path. Perhaps K.HDR.CNT is a path or command, too?
>> 
>> Does this help explain my confusion? My gut says I am confused by 
>> syntax differences between what I learned in Merlin and whatever else 
>> this particular source was assembled in.
>> 
>> m
> 
> It's not really so mysterious--take heart!  ;-)
> 
> Assemblers mostly differ in fairly trivial ways, such as the mnemonics
> chosen for "pseudo ops" that are *not* machine instructions, but
> instructions to the assembler to reserve data space, define constants, or
> control the listing.  The syntax for describing arithmetic/logical
> expressions as operands may also differ, both in operators used (+, -, ^
> [exor], etc.) and in complexity of operations permitted. 
> 
> In the example you give, the pseudo-op is "dw", which stands, as you
> guessed, for "double word"--in this case, a two-byte data item. Its operand
> is an expression which is evaluated as a 16-bit quantity by the assembler,
> then used as the (initial) value of the two-byte field. In this case, the
> value is the value of the symbol LDR.ADR minus the value of the symbol
> K.DRIVES, which is apparently $0062. 
> 
> The leftmost field of virtually every assembly line is an optional label,
> which gets defined as the current value of the location counter, which
> corresponds to the address of the first generated byte (if any) for this
> line. 
> 
> So, for each assembly line:
> 
> <optional label>  <op/pseudo-op>  <optional operand expression>  <;
> optional comment>
> 
> And each listing line is the source line preceded by:
> 
> <current location counter> <generated data> <source file line number> 
> 
> The <generated data> may be truncated to a few bytes to keep the listing
> down to one line per source line, but it's all still there in the object
> code file.  (This "unlisted" data is one thing that could lead to incorrect
> results if the hex visible in the listing is just typed into the monitor.)

I should have noted that for symbol-defining pseudo-ops, like "equ"
("equate"), the label is defined not as the current location counter, but
as the value of the operand expression. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2008

On 2015-12-12 22:04:12 +0000, Michael J. Mahon said:

> It's not really so mysterious--take heart!  ;-)

Ah! Heh. I find your coming in here quite nice. A wizard appears! ;-)

> Assemblers mostly differ in fairly trivial ways, such as the mnemonics
> chosen for "pseudo ops" that are *not* machine instructions, but
> instructions to the assembler to reserve data space, define constants, or
> control the listing.  The syntax for describing arithmetic/logical
> expressions as operands may also differ, both in operators used (+, -, ^
> [exor], etc.) and in complexity of operations permitted.

Yes, I think I understand that. My only experience is with Merlin and 
the earliest one at that. So, I've been introduced to a lot of the 
concepts, psuedo ops among them. I haven't peeked at any other 
assemblers except for bringing up EDASM one time in a virtual 
environment and realizing how different it was from Merlin.

> In the example you give, the pseudo-op is "dw", which stands, as you
> guessed, for "double word"--in this case, a two-byte data item. Its operand
> is an expression which is evaluated as a 16-bit quantity by the assembler,
> then used as the (initial) value of the two-byte field.

Roger.

> In this case, the
> value is the value of the symbol LDR.ADR minus the value of the symbol
> K.DRIVES, which is apparently $0062.

This is something new for me, Symbols. I take it there is a symbol 
table that is not part of this PDF?


> The leftmost field of virtually every assembly line is an optional label,
> which gets defined as the current value of the location counter, which
> corresponds to the address of the first generated byte (if any) for this
> line.
> 
> So, for each assembly line:
> 
> <optional label>  <op/pseudo-op>  <optional operand expression>  <;
> optional comment>
> 
> And each listing line is the source line preceded by:
> 
> <current location counter> <generated data> <source file line number>
> 
> The <generated data> may be truncated to a few bytes to keep the listing
> down to one line per source line, but it's all still there in the object
> code file.  (This "unlisted" data is one thing that could lead to incorrect
> results if the hex visible in the listing is just typed into the monitor.)

Ok. So, in this case, we have the assembly source but not necessarily 
the object code (or symbol table) that could be used to assemble SOS 
from scratch? Does that mean this particular source is incomplete?

Thanks again, Michael (and everyone else). This is really helping.

Cheers,

Mike...

[toc] | [prev] | [next] | [standalone]

#2009

ultramagnus_tcv <mikew@thecomputervalet.com> wrote:
> On 2015-12-12 22:04:12 +0000, Michael J. Mahon said:
> 
>> It's not really so mysterious--take heart!  ;-)
> 
> Ah! Heh. I find your coming in here quite nice. A wizard appears! ;-)
> 
>> Assemblers mostly differ in fairly trivial ways, such as the mnemonics
>> chosen for "pseudo ops" that are *not* machine instructions, but
>> instructions to the assembler to reserve data space, define constants, or
>> control the listing.  The syntax for describing arithmetic/logical
>> expressions as operands may also differ, both in operators used (+, -, ^
>> [exor], etc.) and in complexity of operations permitted.
> 
> Yes, I think I understand that. My only experience is with Merlin and 
> the earliest one at that. So, I've been introduced to a lot of the 
> concepts, psuedo ops among them. I haven't peeked at any other 
> assemblers except for bringing up EDASM one time in a virtual 
> environment and realizing how different it was from Merlin.
> 
>> In the example you give, the pseudo-op is "dw", which stands, as you
>> guessed, for "double word"--in this case, a two-byte data item. Its operand
>> is an expression which is evaluated as a 16-bit quantity by the assembler,
>> then used as the (initial) value of the two-byte field.
> 
> Roger.
> 
>> In this case, the
>> value is the value of the symbol LDR.ADR minus the value of the symbol
>> K.DRIVES, which is apparently $0062.
> 
> This is something new for me, Symbols. I take it there is a symbol 
> table that is not part of this PDF?

Most likely, the listing you are looking at is not the complete assembly
listing, but just a part. The symbols that are apparently undefined are
defined (either as labels or as "equ"s) elsewhere in the complete listing. 

Even if the program is created from separately assembled modules that are
linked together, each module listing would have pseudo-ops that specify
which symbols are "imported" from other modules or "exported" to other
modules.

>> The leftmost field of virtually every assembly line is an optional label,
>> which gets defined as the current value of the location counter, which
>> corresponds to the address of the first generated byte (if any) for this
>> line.
>> 
>> So, for each assembly line:
>> 
>> <optional label>  <op/pseudo-op>  <optional operand expression>  <;
>> optional comment>
>> 
>> And each listing line is the source line preceded by:
>> 
>> <current location counter> <generated data> <source file line number>
>> 
>> The <generated data> may be truncated to a few bytes to keep the listing
>> down to one line per source line, but it's all still there in the object
>> code file.  (This "unlisted" data is one thing that could lead to incorrect
>> results if the hex visible in the listing is just typed into the monitor.)
> 
> Ok. So, in this case, we have the assembly source but not necessarily 
> the object code (or symbol table) that could be used to assemble SOS 
> from scratch? Does that mean this particular source is incomplete?

Yes, exactly. 

> Thanks again, Michael (and everyone else). This is really helping.
> 

Excellent!  

Keep at it, and it will all make sense. ;-)

You may have already done it, but a careful reading of the Apple II Monitor
ROM listing (which *is* complete) will prove very rewarding.
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2010

On 2015-12-13 17:23:42 +0000, Michael J. Mahon said:

> You may have already done it, but a careful reading of the Apple II Monitor
> ROM listing (which *is* complete) will prove very rewarding

This is something I peeked at before I read Assembly Lines and you can 
imagine how that went.

It would be easier now. Thank you again.

And thanks to every one else for responding. 

[toc] | [prev] | [next] | [standalone]

#2011

ultramagnus_tcv <mikew@thecomputervalet.com> wrote:

> On 2015-12-12 22:04:12 +0000, Michael J. Mahon said:
> 
> > In the example you give, the pseudo-op is "dw", which stands, as you
> > guessed, for "double word"--in this case, a two-byte data item. Its operand
> > is an expression which is evaluated as a 16-bit quantity by the assembler,
> > then used as the (initial) value of the two-byte field.
> 
> Roger.

I'd suggest that "dw" is more likely "define word" rather than "double
word", because that matches "dfb" or "db" as "define byte". It is still
a two byte data item.

The use of the term "word" is rather arbitrary. It should refer to the
native word size of the processor (which would be 8 bits for a 6502 or
65C02) but it is quite common to refer to a "word" as 16 bits on an 8
bit processor.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#2012

David Empson <dempson@actrix.gen.nz> wrote:
> ultramagnus_tcv <mikew@thecomputervalet.com> wrote:
> 
>> On 2015-12-12 22:04:12 +0000, Michael J. Mahon said:
>> 
>>> In the example you give, the pseudo-op is "dw", which stands, as you
>>> guessed, for "double word"--in this case, a two-byte data item. Its operand
>>> is an expression which is evaluated as a 16-bit quantity by the assembler,
>>> then used as the (initial) value of the two-byte field.
>> 
>> Roger.
> 
> I'd suggest that "dw" is more likely "define word" rather than "double
> word", because that matches "dfb" or "db" as "define byte". It is still
> a two byte data item.
> 
> The use of the term "word" is rather arbitrary. It should refer to the
> native word size of the processor (which would be 8 bits for a 6502 or
> 65C02) but it is quite common to refer to a "word" as 16 bits on an 8
> bit processor.
> 

Agreed, David--thanks for the correction. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2013

On 13/12/2015 2:15 PM, David Empson wrote:
 > ultramagnus_tcv <mikew@thecomputervalet.com> wrote:
 >
 >> On 2015-12-12 22:04:12 +0000, Michael J. Mahon said:
 >>
 >>> In the example you give, the pseudo-op is "dw", which stands, as you
 >>> guessed, for "double word"--in this case, a two-byte data item. Its 
operand
 >>> is an expression which is evaluated as a 16-bit quantity by the 
assembler,
 >>> then used as the (initial) value of the two-byte field.
 >>
 >> Roger.
 >
 > I'd suggest that "dw" is more likely "define word" rather than "double
 > word", because that matches "dfb" or "db" as "define byte". It is still
 > a two byte data item.

I'm with you on that. DW is define word (two bytes), DB is define byte 
(one byte), DS is define storage (arbitrary number of bytes). At least 
in the Orca languages.

 > The use of the term "word" is rather arbitrary. It should refer to the
 > native word size of the processor (which would be 8 bits for a 6502 or
 > 65C02) but it is quite common to refer to a "word" as 16 bits on an 8
 > bit processor.

I'm not sure why anyone ever thought that making the definition of a 
term be dependent on the architecture of the processor was a good idea. 
I've run into it with PCs where the default size of integer variable 
types were 16 bit for one language and and 32 bit for another. To me it 
has always been a that a byte is 8 bits, a word is 16 bits and a double 
word is 32 bits.

[toc] | [prev] | [next] | [standalone]

#2014

Jeff Blakeney <CUTjeffrey_blakeney@yahoo.ca> wrote:
> On 13/12/2015 2:15 PM, David Empson wrote:
>> ultramagnus_tcv <mikew@thecomputervalet.com> wrote:
>> 
>>> On 2015-12-12 22:04:12 +0000, Michael J. Mahon said:
>>> 
>>>> In the example you give, the pseudo-op is "dw", which stands, as you
>>>> guessed, for "double word"--in this case, a two-byte data item. Its 
> operand
>>>> is an expression which is evaluated as a 16-bit quantity by the 
> assembler,
>>>> then used as the (initial) value of the two-byte field.
>>> 
>>> Roger.
>> 
>> I'd suggest that "dw" is more likely "define word" rather than "double
>> word", because that matches "dfb" or "db" as "define byte". It is still
>> a two byte data item.
> 
> I'm with you on that. DW is define word (two bytes), DB is define byte 
> (one byte), DS is define storage (arbitrary number of bytes). At least 
> in the Orca languages.
> 
>> The use of the term "word" is rather arbitrary. It should refer to the
>> native word size of the processor (which would be 8 bits for a 6502 or
>> 65C02) but it is quite common to refer to a "word" as 16 bits on an 8
>> bit processor.
> 
> I'm not sure why anyone ever thought that making the definition of a 
> term be dependent on the architecture of the processor was a good idea. 
> I've run into it with PCs where the default size of integer variable 
> types were 16 bit for one language and and 32 bit for another. To me it 
> has always been a that a byte is 8 bits, a word is 16 bits and a double 
> word is 32 bits.

Well, an assembler *is* about the most architecture-dependent language
imaginable. ;-)

Back when assemblers were invented, "word" quite naturally meant whatever
"word" meant for the target machine, whether it was 40 bits, 36 bits, or
whatever.  

The smallest addressable unit was the "word", and that was the default size
for integers, and often for single-precision floating-point. 

When almost all machines became byte-addressed (with the IBM 360), the
situation became more ambiguous, though "word" on large machines continued
to be 32 bits, with 16 bits being a "halfword". 

As micro architectures continued to grow, first to 16-bit registers and
then 32-bit registers and beyond, the "word" nomenclature became hopelessly
confused, and is now deprecated in favor of an explicit designation of bit
length. 

Fortunately (?), the 6502 architecture has only been expanded once, and a
desire for assembler compatibility has kept a 65x02 "word" as 16 bits. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2169

Monday, December 14, 2015 at 9:17:23 AM UTC+10, Jeff Blakeney wrote:
> I'm not sure why anyone ever thought that making the definition of a 
> term be dependent on the architecture of the processor was a good idea. 
> I've run into it with PCs where the default size of integer variable 
> types were 16 bit for one language and and 32 bit for another. To me it 
> has always been a that a byte is 8 bits, a word is 16 bits and a double 
> word is 32 bits.

Yes, I tend to agree with these definitions.  However, like you said, some environments are "weird".  e.g. CDC Cyber maintframes had a 64 bit word.

[toc] | [prev] | [next] | [standalone]

#2170

<m.omalley.au@gmail.com> wrote:
> Monday, December 14, 2015 at 9:17:23 AM UTC+10, Jeff Blakeney wrote:
>> I'm not sure why anyone ever thought that making the definition of a 
>> term be dependent on the architecture of the processor was a good idea. 
>> I've run into it with PCs where the default size of integer variable 
>> types were 16 bit for one language and and 32 bit for another. To me it 
>> has always been a that a byte is 8 bits, a word is 16 bits and a double 
>> word is 32 bits.
> 
> Yes, I tend to agree with these definitions.  However, like you said,
> some environments are "weird".  e.g. CDC Cyber maintframes had a 64 bit word.
> 

It was 60 bits, right?

The CDC architecture was designed before powers of two and
byte-addressability became "standard".

Among other things, this led to a 60-bit limit to set sizes in ETH Pascal. 

In fact, "word" originally meant the smallest addressable unit and the size
of the accumulator(s), and varied widely with processor architecture,
commonly from 12 to 60 bits.

The ambiguity started when byte-addressability became widespread and a
multi-byte unit ("word") was defined as something "big enough" to hold an
"integer" or an address. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2171

The IBM 704/709/7090/7094 had 36 bit words and 15 bit addresses. One of the most maddening things about reading 704 code is that the instructions were word length but quite sparse and had a lot of unused bits, so programmers would use the spare bits of various instructions to store addresses, temporary variables, etc.

[toc] | [prev] | [next] | [standalone]

#2172

<wssimms@gmail.com> wrote:
> The IBM 704/709/7090/7094 had 36 bit words and 15 bit addresses. One of
> the most maddening things about reading 704 code is that the instructions
> were word length but quite sparse and had a lot of unused bits, so
> programmers would use the spare bits of various instructions to store
> addresses, temporary variables, etc.
> 
Though, even then, this practice was deprecated (unless space was critical
and it was a beautiful hack ;-).

And the most convenient layout for storing pointers in the 36-bit word was:
<3-bit "prefix"><15-bit "decrement" pointer><3-bit "index"><15-bit
"address" pointer>

The 3-bit fields made great "tag" bits for Lisp, and the dereferencing
functions for the pointers naturally became "car" (Contents of Address
Register) and "cdr" (Contents of Decrement Register). 

Ah, the late nights I spent with the Caltech 7094... ;-)

A typical subroutine call:

  TSX SUBR,4   ; Transfer (to SUBR) and set index 4 (to *+1)
  PZE ARG1       ; Plus zero (with ARG1 in address field)
...
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2175

It's a shame that "modern" architectures don't use a link register to make function calls. It makes inline arguments so easy. Of course it also pretty much necessitates writing into the text segment with all of the problems that entails (or putting code in the data segment like old versions of UNIX used to do -- also problematic).

I've read a lot of 704 code but it's too bizarre to my mentality (formed in the 80s and 90s) for me to really like it. But PDP-11 code is just about perfect.

Someday I'm going to write the ultimate IBM 704 simulator, with a 3D graphics virtual reality interface. I want to BE in that machine room, watch the tape zip up and down in the vacuum columns, hear the card reader slurp in a stack of cards, and flip the flippin toggle switches on the console.

[toc] | [prev] | [next] | [standalone]

#2188

<wssimms@gmail.com> wrote:
> It's a shame that "modern" architectures don't use a link register to
> make function calls. It makes inline arguments so easy. Of course it also
> pretty much necessitates writing into the text segment with all of the
> problems that entails (or putting code in the data segment like old
> versions of UNIX used to do -- also problematic).
> 
> I've read a lot of 704 code but it's too bizarre to my mentality (formed
> in the 80s and 90s) for me to really like it. But PDP-11 code is just about perfect.
> 
> Someday I'm going to write the ultimate IBM 704 simulator, with a 3D
> graphics virtual reality interface. I want to BE in that machine room,
> watch the tape zip up and down in the vacuum columns, hear the card
> reader slurp in a stack of cards, and flip the flippin toggle switches on the console.
> 

Hear, hear!  The thundering of the modified 407 console printer was a
hallmark of these systems. 

The IBSYS IOCS (Input/Output Control System) was my tutorial on interrupts
and synchronization. 

We had installed a patch in the (local) macro assembler that would cause it
to pause for console patches if a "magic" number was set in the console
switches. ;-)

That 7094 was, indeed, a personal computer for a small and hearty band! 
During the day, when the 7094 was a closed-shop workhorse spooled by a
7044, a Burroughs 220 was the "personal computer". Users signed up for
blocks of time on a blackboard. (Wrote my first music program on the 220,
requiring a transistor radio for listening. ;-)
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#2190

On Friday, December 11, 2015 at 8:50:44 AM UTC-8, Chris Torrence wrote:
> You might take a look at Assembly Lines: The Complete Book: 
> http://www.lulu.com/shop/roger-wagner/assembly-lines-the-complete-book/hardcover/product-21959093.html 
> http://amzn.com/1312089407

I'll second (third?) that recommendation too.

Even though I have most of the 6502 opcodes memorized for the past 30 years, I picked a copy up in 2014 (or 2015) to see how good it was.

It a _fantastic_ introduction to 6502 assembly programming.  Very well written.

The earlier 1982 edition "Assembly Lines: The Book" is also good.
http://chiclassiccomp.org/docs/content/books/AssemblyLines6502ProgrammingAppleII_RogerWagner.pdf

[toc] | [prev] | [next] | [standalone]

#2003

Am Samstag, 12. Dezember 2015 01:06:18 UTC+9 schrieb ultramagnus_tcv:
> Hey folks,
> 
> I come before you humbled by the fact that I have no idea how to read 
> source files. Oh, I can read English and I have a passing familiarity 
> with 6502 assembly, but I don't understand some (basic?) things about 
> it.
> 
> I have a few questions and I hoped I could be set straight on:
> 
> 1. Are the numbers on the left typical of where the program resides in 
> memory rather while running than on disk?

They are a running count of locations used by the object code.
They may or may not have anything to do with where the code
will reside in memory.

> 2. If there is no accompanying information with the source, how does 
> one figure out what assembler was using to write the code? For 
> instance, does Apple always use EDASM? (I did most of my studies in 
> Merlin.)

Usually you guess based on the specifics of the syntax. It is
usually fairly straightforward to translate a given piece of code
for any assembler. If all you are do is reading, it doesn't really
matter that much anyway.

> 3. If one were a masochist, could one enter the hexadecimal values on 
> the left into, say, the monitor?

Yes, but unless everything is at the correct location, it probably
won't run correctly.

> 4. I've been told that you can't merely identify the assembler used and 
> then re-type the code into that assembler and expect it to assemble 
> and/or run. Why would that be?

Actually that should work just fine, provided you really have all
of the source code. It is entirely possible that you don't have macro
libraries, etc. In which case, you would need to recreate the macros
before you could assemble the source.

> I apologize if these are dumb questions. As I investigate the Apple 
> ///, I often find people refer me to the source. But if I can't read 
> it.........?

I agree with Chris. You need to study a bit more. Given that you already
have some familiarity with assembly code, you shouldn't find it very
difficult to get up to speed.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web