Subject:
Re: More nocturnal programming problems
From:
"Paul B. Webster" ####@####.####
Date:
17 Mar 2004 11:59:01 +0000
Message-Id: <1079524721.3402.30378.camel@dads.webstermed>
On Wed, 2004-03-17 at 13:36, Craig Franklin wrote:
> gpasm does allow forward references to symbols, so this isn't always
> true. It takes two passes of the source code.
Oops! That *is* what two-pass assemblers are about, of course. I am
pontificating without, at this point, actually using the thing - in
fact, I am woefully out of practice - it shows, doesn't it?
OK, it perhaps doesn't matter whether the code block itself is early
or late in the program as long as dependent variables (the "EQU" one)
follow after all variables upon whose actual value they depend. Pass
one generates the symbol table defining the value of all the symbols,
which may then be used wherever referenced in pass two.
Pass two actually resolves all the symbols again, but only to check
them against those already present in the symbol table, giving the error
specified if they disagree.
> Without seeing all of his source code, it is difficult to know which is
> best.
As a general approach to string handling, the only matter of concern
is whether the "message" is binary or text. Text data is almost
universally (FORTH excepted) stored in zero-terminated strings (as I
recall, MPASM provides for these,) because you only require a single
pointer to represent the string. For binary strings, you require either
start and end(+1) pointers, or a pointer to the string which is itself
prefixed by a length descriptor (byte or word, depending on the maximum
length string to be permitted).
There can be few exceptions to the rule that passing a single pointer
is more concise than passing two pointers because the code required to
load the second pointer for every call is always (much) more expensive
than either the terminator (null) word or the length prefix to the
corresponding string (especially where the string is used more than
once), and within the output subroutine, a test (branch) for zero or
iteration counter (DJNZ) is far more efficient than a comparison-for-end
procedure.
Revisiting the code in question, if "message" is in fact binary and
strings limited to less than 256, we should be able to use:
message_start:
retlw msg_len-1
retlw b'00000000'
[... etc ...]
retlw b'11111111'
message_end:
msg_len EQU (message_end - message_start)
... in conjunction with a subroutine that reads the first element into
the loop counter.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My apologies - I had not noticed that this list works in a most
annoyingly non-standard fashion, and my reply went to Craig only!
On Wed, 2004-03-17 at 13:36, Craig Franklin wrote:
On Tue, 2004-03-16 at 06:34, Paul B. Webster wrote:
> On Tue, 2004-03-16 at 13:06, Craig Franklin wrote:
>
> > Symbols assigned a value using EQU can't be changed.
>
> But really, that's not the most important thing. What is important,
> is the concept of the "pass" - that message_start and message_end must
> be defined before *anything* that uses them.
>
> Your code then needs to read:
>
> message_start:
> retlw b'00000000'
> [... etc ...]
> retlw b'11111111'
> message_end:
>
> msg_len EQU (message_end - message_start)
>
> ... and by the same token, whatever code uses msg_len, must follow
> after all three declarations.
>
gpasm does allow forward references to symbols, so this isn't always
true. It takes two passes of the source code.
> In practice, this demands that your message blocks appear after the
> initial "start jmp begin" code, and before the subroutines
which
> reference them.
>
> Of course, most message print routines use a zero-terminated string
> anyway, because the code to detect the zero is vastly more concise
than
> code which requires two parameters (pointer and length) to call.
>
> Have I missed something?
Without seeing all of his source code, it is difficult to know which is
best.
--
Cheers,
Paul B.
