Newsgroups: alt.folklore.computers
Subject: Re: octal to decimal converter?
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 22 Dec 92 10:47:45 GMT
Distribution: world
Organization: The Wolery

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.

> Same total storage, but more useful for longer blurbs.  Also, it would be
> 12-bits shorter if I used non-locking case shift, but as I indicated earlier,
> I really do prefer locking shifts.  Also the 7600 constant is easily bummed
> out (see below).  So, the code is 120 bits here also.  Besides, I don't think
> much is being served counting the characters in the blurbs, although the VAX
> and most other machines have little useful facility to take advantage of
> character sets other than the usual because of the 8-bittedness of the
> machines.  Only the -8 and -10 really optimize for six-bit data. (The -10
> can do any length.)  None-the-less, as the blurb gets longer, the overall
> PDP-8 size will tend to get even smaller since blurbs are stored in six-bit
> compressed form.  (Of course there are perverse cases where the shift overhead
> exceeds the advantages.  This is why we use both locking and non-locking shift
> routines, etc.)

Well, the "specification" was to print out "Hello World!" by whatever means;
for a competition in economy, the text should be included, since the
representation can greatly effect the routine.

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....  

> >Also, your algorithm using a lookup table doesn't scale nicely on long 
> >word machines -- imagine a hypothetical 32 bit PDP-8.... 8-)  'course
> >EDIV on the VAX helps a LOT here.
>
> Irrelevant; the technique applies to the problem as defined.  I could have
> also used the longer divide by 10 method to crank out the digits in reverse

True, except that if I did a 12-bit conversion I could cut that filthy
great 32-bit 10^9 constant in my code down to 16 bits.  

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

> order, which I object to in your examples, using tricks to get strings 
> outputted by putting them together backwards as in the Hello World program.
> At least my character strings are in normal order.  In any case, I can
> bum a few more words out of this code, which while not the first-order
> thing to do, none-the-less does happen:

Like I said, it was a case of "Hello World", any way you please.  Saner code
would go:

	hello:	.ascii "Hello, World!"
		.byte 13
		.byte 0

	routin:	movab hello, R1
	  1$:	movzbl (R1)+, R0
		beql 2$
		bsb output
		brb 1$
	  2$:	rsb

	15 bytes data, 14 bytes code, 29 bytes total
	120 bits data, 112 bits code, 232 bits total

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-)

>      	Instructions:	25
>      	Code:		26 12-bit words
>      	Data:		 5 12-bit words
>      	Total:		31 12-bit words
> 
>         This version is 372 bits total.  A minor model cheat is that R3L can't
> be used on some earlier machines.  The locations marked with Lxxxx are bummed
> away locations:
> 
> L7600,  CLA!400         /CLEAR THE ACCUMULATOR AND ALSO A GOOD CONSTANT
> 
> L7720,  SMA SNL CLA     /CLEAR THE ACCUMULATOR AND IT MIGHT SKIP
> L60,    AND     60      /HARMLESS .AND. INSTRUCTION; IT MIGHT BE SKIPPED OVER
> 
> These would be used to replace ordinary CLA instructions that are always
> needed in numerous places.  (You did ask for *real* examples, well this is
> what *really* is done.)
> 
> Who's sorry now?  (Connie Francis)

Who indeed?

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-)

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
Xref: sparky alt.folklore.computers:18271 sci.math:17347 comp.compression:4216