gnupic: More nocturnal programming problems
Subject:
Re: More nocturnal programming problems
From:
David Willmore ####@####.####
Date:
17 Mar 2004 17:09:48 +0000
Message-Id: <200403171700.i2HH0NqX025665@localhost.localdomain>
> Paul wrote:
> 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.
This would seem to preclude forward references. If the symbol has no
value (is not defined) when it is used, then a later definition will
no propogate back?
> > Without seeing all of his source code, it is difficult to know which is
> > best.
It's no secret, it's just no complete and I couldn't see how any more than
what was shown was meaningful, sorry. Shall I post it here? It's still
not quite complete, so please pardon the mess. :) Basically, before
that table, there is a little prolog that goes:
data_lookup:
movwf PCL_tmp
movlw LOW data_table ; load in the low byte of the table data start address
addwf PCL_tmp,f
movlw HIGH data_table ; load in the high byte of the table data start address
btfsc STATUS,C ; skip if carry clear
addlw 1 ; stuff in the carry bit
movwf PCLATH ; stick it in the high byte PC latch
movf PCL_tmp,w ; load in the PCL value
movwf PCL ; jump
data_table:
; Char 1 'W'
retlw b'01111110'
retlw b'10000000'
retlw b'01111000'
...
data_end:
You set the index in w and call data_lookup. Yeah, there's probably a
cleaner way to do this, but it handles tables up to 256 bytes and they
can straddle pages. And, it wouldn't be all too hard to extend it to
being able to use all of memory.
The site using the EQU just runs a counter from 0 up until the length
define value -1. (it's a modulo operation as the message is a scrolling
banner that loops forever).
> 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).
For really specific strings, I just have a binary string and a programatic
constant for the length. Call it 'none of the above'. :) Maybe a pascal
string with a displaced length value?
> 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.
What about addressing the buffer with the pointer % the length? :)
> 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.
Which precludes using the length as a literal value--now it has to be in a
memory location or register. For embeddid (i.e. tiny) processors that can
count precious bytes.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> My apologies - I had not noticed that this list works in a most
> annoyingly non-standard fashion, and my reply went to Craig only!
That's a religious argument for another day! ;)
Thanks for the advice.
Cheers,
David
