PDA

View Full Version : CP/M 2.2 strings and variable addresses



Mike_Z
October 21st, 2016, 09:13 AM
I'm still a little new to CPM 2.2 assembly language, but am learning a lot. I have a couple of house keeping questions regarding variables and strings.

1st, variables that are saved at a memory address, this works


DEST EQU 05000H
SOURCE EQU 05002H
ERROR EQU 05004H


but this fixes these address. I figure this is a better method.


Some CODE

DEST: DB 00H
DS 02H
SOURCE: DB 00H
DS 02H
ERROR DB 00H
DS 02H

MORE code


OR..... would this be even better?


Some CODE

DEST: DW 0000H
SOURCE: DW 0000H
ERROR DW 0000H

MORE code


Then does it matter where in the code these addresses are placed? I've been putting them all at the end of the code, but can they be placed withing the code?

2nd strings. I've been placing strings in the code like this



ER1: DB 'This is error 1 message',024H
ER2: DB 'This is error 2 message',024H
ER3: DB 'This is error 3 message',024H



I know that this works, but is there a better way?

I appreciate the help. Mike

Chuck(G)
October 21st, 2016, 09:26 AM
All will probably work, but there's a matter of making readable code. Please allow me to elucidate...

If something will be accessed as a word, it's best to use "DW" to define it. Examples of words are 16-bit integers, address pointers, etc. That is, both bytes are inexorably related and treated as 16-bit quantities. It's unfortunate that ASM only has "DS" to reserve uninitialized storage, so you have no idea what's really intended. 8086 assembler clears this up by using the notation of (?) and DUP to indicate exactly what the eventual datatype is; e.g.,
WORDBUF DW 16 DUP (?) ; define a 16 word buffer
--but that's not available with ASM.

Secondly, encoding ASCII as hex is misleading to someone reading your source. 24H is a "dollar sign" and so should be encoded that way. Additionally, you'll want to terminate your messages with a carriage return-linefeed combination, or else any subsequent output will start on the same line right after your error message. ASCII CR is 0DH, and LF is 0AH, so why not make them symbolically equivalent? So, your three messages would be coded as:



CR EQU 13 ; carriage return
LF EQU 10 ; line feed

ER1: DB 'This is error 1 message',CR,LF,'$'
ER2: DB 'This is error 2 message',CR,LF,'$'
ER3: DB 'This is error 3 message',CR,LF,'$'


Finally, please comment your code! It costs nothing in terms of storage and makes your code easier to understand.

Mike_Z
October 21st, 2016, 09:41 AM
Thanks for the reply. My old home made assembler forced me to use ASCII, so It's a habit that I need to work on to change. I'm just getting used to using HEX rather than SPLIT OCTAL. Commenting code is a difficult thing, especially while the code is being debugged, because of all the changes. Then when the code works it is easy to say I'll get a round to it later. Then many of my comments are just a rephrase of that the mnemonic is. Which doesn't help at all. Work I have been attempting to do is to make a general comment at the start of each routine label and to use English to describe what is to be accomplished. Then just add some clarifying comments to anything that is odd within the routine. I also provide a header to each program with some details about the purpose and what it generally does. I do this for my library files also. Anyway thanks for the help Mike

Chuck(G)
October 21st, 2016, 09:59 AM
You're on the right track. Best practice generally follows that of news reporting: A block comment saying what you're going to do and how you're going to do it; a running commentary while you're doing it; and finally, a brief statement saying what you've done (so the reader knows where the commentary ends).

I fault much of Linux code with lousy commentary--pawing one's way through some of it can really bring on the migraines. It gets worse when there is a mixture of languages involved.

The trick is to keep your commentary fresh and relevant as you make changes. Look at some of Microsoft's code for Windows or even MS-DOS and you'll see references to functions and references that no longer exist. Windows NT, when it first came out, had beautiful commentary. Probably not so much any more--I've not seen any Win10 source--but it was pretty bad by the time of XP.

DDS
October 21st, 2016, 11:31 AM
"I fault much of Linux code with lousy commentary--pawing one's way through some of it can really bring on the migraines."

I feel yo' pain. ;-)

The source code for the #1ESS was (mostly) written in a macro assembler by a German guy and his wife, neither of whom had English as their first language. Usually the macros were not defined in the 3" thick binder you were reading from, but in another 3" thick binder back on the racks of hundreds of feet of identical looking binders. Then when the #1AESS was developed, a cross assembler was used to convert the #1ESS assembler source into #1AESS assembler source. The #1ESS code was included as the comment field and the original #1ESS comments dropped. So if you were working on one of the #1ESS machines, you might have only two binders open, one for the macro source and one for the main source. If you were working on a #1AESS, well, now you had to add minimum one more so you could see the macro, the #1AESS source, and another for the #1ESS source to see the original comments.

Our routine in the control center was to do Audit History Analysis (audits printed by the switches were collected and organized into AHA reports) on Wednesdays. Audit History Analysis consisted of attempting to make some sense of these cryptic octal dumps by searching through the relevant assembler source listing to try and figure out what had made the machine unhappy enough to print out the audit message.

Typically one of us "analyzers" would start off "AHA Migraine Wednesday" by slapping down a bottle of Migraine Extra Strength Excedrin on one of our desks for communal use. And use them we did!

Chuck(G)
October 21st, 2016, 02:03 PM
Heh. I can recall being a couple of those situations of "Don't touch it--you might break it and nobody knows how it works" code. Eventually, some poor sod is tasked with extending the functionality of a software product and it invariably involves one of the "poison ivy" routines. In those cases, more than Excedrin is needed... :)