Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!stanford.edu!shap@shasta.Stanford.EDU
From: shap@shasta.Stanford.EDU (shap)
Newsgroups: comp.lang.c++
Subject: Re: 64 bit architectures and C/C++
Message-ID: <172@shasta.Stanford.EDU>
Date: 29 Apr 91 03:40:55 GMT
References: <168@shasta.Stanford.EDU> <224@tdatirv.UUCP> <295@dumbcat.sf.ca.us>
Organization: Stanford University Computer Systems Laboratory
Lines: 19

In article <295@dumbcat.sf.ca.us> marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
>In article <224@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:

> > If there are no instructions for 16 bit quantities
> > then using 16 bit short's is a big loss.
>
>Hmmm.  How would such a processor communicate with hardware devices requiring
>16-bit I/O?

The answer, given the machine he poses, is that it doesn't, since it
doesn't support 16 bit ops.  You could build such a machine, provided
you were willing to do all the peripherals yourself (I'm not
recommending).

However, there is a more compelling argument for 16 bit types in RPC,
extended precision math routines, etc.  'short' has the (un?)fortunate
property that it has been 16 bits on almost every machine known to
man, and a depressing amount of code appears to make the 
sizeof(short) == 16 bits assumption.