I don't see where it makes much difference In general in BASIC but in this
case there is a justification for MSB first ;-)
It goes from MSB to LSB because the same routine does 4 or 2 digits
depending on where you enter; line 5 gives the 4 digit address and it falls
through to line 7 which also gives the 2 digit bytes peeked and creates the
ASCII value for the text on the right hand side.

I suppose going the other way I'd always have to start at the beginning and
return after two digits* 'if'* doing peeks instead of addresses; more
complicated IMO.

m


On Thu, Oct 27, 2022 at 6:04 PM John R. Hogerhuis <jho...@pobox.com> wrote:

>
>
> On Thu, Oct 27, 2022 at 1:10 PM MikeS <dm...@torfree.net> wrote:
>
>> More good tips, thanks. Yes, I have to look at defining the various
>> types, especially the ones that can go above 32768.
>>
>> Concatenation with '+' is a habit from other languages I've worked with;
>> as a matter of fact in most cases the M100 lets you print without any
>> separators at all, e.g. print A$" to "B$ or a"plus"b
>>
>> Interesting discussion (at least for some of us ;-) )
>>
>>
>
> One overall thing in outputting numbers in any radix, is that it is
> *usually* most tractable in reverse of how you output since we generally
> write/read numbers with the most significant digit first. So for generating
> a number to output, It is most efficient to extract the least significant
> digit, shift or otherwise divide by the radix, prepend the extracted number
> onto a string/buffer, and when the value gets to zero, you're done, output
> the string.
>
> So for the number 1235 in decimal,
>
> 1235 MOD 10 = 5. Prepend ASC('0') + 5 on buffer. Divide remaining value by
> 10
> 123 MOD 10 = 3. Prepend  ASC('0') + 3 on buffer.  Divide remaining value
> by 10
> 12 MOD 10 = 2.  Prepend  ASC('0') + 2 on buffer.  Divide remaining value
> by 10
> 1 MOD 10 = 1. Prepend  ASC('0') + 1 on buffer. Divide remaining value by 10
> Remaining value is 0, so we're done. Buffer contains the number
>
> In your subroutine at 5 it is doing it MSB to LSB, I think. Overall your
> way may still be faster in BASIC even with the larger divisors.
>
> With hex it's a question though since MOD 16 can be done with AND 15 which
> is probably faster than a general integer 16 modulus. There's no bitshift
> operator so you still need a integer divide by 16%. Who knows how efficient
> an integer divide by 16 is in the interpreter versus 4096 (integer)
> divides.
>
> -- John.
>
>>

Reply via email to