From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: octal to decimal converter?
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Wed, 23 Dec 1992 00:40:29 GMT

In article <13921356@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> Yes, but it still adds 32 more bits to the instruction to have to fetch all
>> of those extra bytes in the addresses.  The -8 version is 2 instructions and
>> 24 bits total, 4 machine cycles in all.
>
>Hardly fair, since this _is_ a 16 bit machine.  It's still three word fetches
>vs four, assuming "long" arbitrary addresses in word-width address space.

I know, it's really terrible having to use a 16-bit machine; those extra
bits really hurt you.

>
>For a general print routine, I think working storage and constants should
>be included (after all, it does add to total code size).  It's fair to knock 
>off the text to be printed though.  Constants should definitely be included;
>the VAX would come out way ahead on some things if you ditch the 32 bit
>constants....  

No, the necessary constants are necessary.  The text itself doesn't serve to
show anything significant, except that for some machines, the use of a
non-8-bit format can save some space without resorting to some unusual
encoding with high overhead.

>The digits do come out in the right order!  I could have saved a goodly
>number of bytes if it went out backwards.  Sheesh.  

No, the strings are in reverse order.

But, the point is that the reverse deflation method lends itself to multiple
precision since you merely divide by 10 each time, but create the string in
reverse order to printout.

>
>Of course Real Live Code would go:
>
>	hello:	.ascii "Hello, World!"
>		.byte 0
>
>		.entry routin, ^M<>
>		pushab hello
>		calls #1, puts		; C library puts() routine
>		ret
>
>		14 bytes data, 13 bytes code
>
>8-)

	*200

	JMS	MAGIC
	TEXT	"^HELLO ^WORLD!%"

	1 word code
	8 words data
	9 words total
	108 total bits

>
>Using the olde "No more Mr Nice Guy" approach, I'll just quietly convert
>the JSBs to BSBs, and we'll see.  A few other tweaks never go amis...
>
>
>	routin:	clro R0			; Clears R0-R3
>					; R0 clear nullifes next two insts
>					; R3 is high order longword of 64bit R2
>					;    in EDIV, so needs to be clear
>		incl R1			; Start R1 off at 1
>	  1$:	movaq (R0)[R2], R2	; Shift R2 8 bits and insert oct digit
>		bsb input		; Get character
>		mull2 #10, R1		; Bump R1 to a suitable power of ten
>		subl2 #48, R0		; Convert character to octal digit
>		bgeq 1$			; CR < '0'
>
>	  2$:	ediv R1, R2, R0, R2	; Divide R2/R1, quotient (digit) in R0,
>					;               remainder back into R2
>		addl2 #48, R0		; Convert digit to character
>		bsb output		; Output to TTY
>		divl2 #10, R1		; Next digit
>		bneq 2$
>
>		movl #13, R0		; Final CR
>		brb output		; No RSB required
>
>39 bytes.  312 bits.  Your turn.  8-)

I won't give any more examples, but you wanted *real* code; the optimizations
I gave are quite real, not contrived.  However, part of the overhead is in the
contrivance of not having proper input and output routines.  I believe the
main "guts" of the code is shorter than yours, and I would include in the
support routine the *real* routines that would have features like:

get an octal digit string specifying max digits, optionally complaining on
either too much or bad input, etc.  And the output routine would be smarter
depending on the application so there would be leading zero suppression or
replacement with blanks, etc.  Once you add on all that in support packages,
there are a lot of support subroutines that do most of that work.  Of course
some machines have trivial mechanisms for dealing with decimal conversions
so this then becomes a special case in and of itself.

In any case, the point is made:  with all of its complications, it doesn't
seem that a VAX can create significantly tighter code thana PDP-8 RISC
machine.  In some cases, specialized instructions will beat it out, calling
up a lot of hardware to do it, but even then not by much.  And in some cases
it's still too clumsy to do as well.


Considering how much hardware the VAX is, don't you think the problems
that can be so solved are better served by multiple PDP-8's that amass to
the same amount of electronics! :-).

cjl