Path: utzoo!utgpu!water!watmath!clyde!att-cb!ihnp4!chinet!dag
From: dag@chinet.UUCP (Daniel A. Glasser)
Newsgroups: comp.sources.wanted
Subject: Re: Need 16 bit compress for Z8000
Message-ID: <2753@chinet.UUCP>
Date: 23 Feb 88 08:24:35 GMT
References: <188@irs3.UUCP> <443@spectrix.UUCP>
Reply-To: dag@chinet.UUCP (Daniel A. Glasser)
Organization: Chinet - Public Access Unix
Lines: 51

In article <443@spectrix.UUCP> clewis@spectrix.UUCP (Chris R. Lewis) writes:
+In article <188@irs3.UUCP> kbrown@irs3.UUCP (Ken Brown) writes:
+>
+>Does anyone know of a version of compress which will run an a
+>Zilog (Z8000 based) system and handle 16 bits.  The version
+>I have will only work at 12 bits.  If you have such a version
+>could you email a copy to me.
+
+This may be totally impossible, unless your machine allows programs of 
+about 500K or more to run.
+
+Try this: Acquire a copy of the source for compress from 2.11 news and 
+try building it with "M_XENIX" defined (regardless of what version of
+UNIX you're running).  You will also have to change the "#define BITS 12"
+to "#define BITS 16" within the "#ifdef z8000 .... #endif".
+[Grep the source for M_XENIX, if it ain't there, you've got the wrong
+version of compress.  Mail me if you need a copy]
+
+If you are running Xenix, you'll probably only have to override the
+BITS definition.
+
+I *think* this is what's happening: like a 286, a Z8000 is segmented
+with 64K chunks.  Thus, the maximum array size is 64K.  Which corresponds
+to 12 bit compression.  Now, Xenix most often runs on 286 class machines with
+the same limitation.  The compress in 2.11 has been recently hacked to run with
+16 bits under Xenix by fooling around with multiple arrays.  So, you have 
+to override compress.c's selection of 12 bits for compression on a z8000, 
+and use the M_XENIX hacking as well.
+
+If 16 bit compress is possible on your machine, this will get you most 
+of the way...
+
+Good luck.
+-- 
+Chris Lewis, Spectrix Microsystems Inc,
+UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis
+Phone: (416)-474-1955

I have tried this for my Zeus (Unix III) system and it almost worked -- The
Z8000 compiler (segmented) and possibly the Z8000 itself have a problem with
objects that are exactly 64k bytes long when accessing the last element.
I suspect that the same trick used for the XENIX_16 fix could be used with
a small twist to reduce the sub-arrays to < 64k.  I will try this some time
soon, and if I meet with success, I will post the results.

-- 
Nobody at the place where I work	Daniel A. Glasser
knows anything about my opinions	...!ihnp4!chinet!dag
my postings, or me for that matter!	...!ihnp4!mwc!dag
					...!ihnp4!mwc!gorgon!dag
	One of those things that goes "BUMP!!! (ouch!)" in the night.