Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.arch,net.lang.c,net.micro,net.micro.pc,net.micro.68k
Subject: Re: Re: Re: Need 286 "C" benchmark
Message-ID: <2245@sun.uucp>
Date: Thu, 30-May-85 01:46:10 EDT
Article-I.D.: sun.2245
Posted: Thu May 30 01:46:10 1985
Date-Received: Sat, 1-Jun-85 00:57:45 EDT
References: <426@oakhill.UUCP> <8745@microsoft.UUCP> <583@intelca.UUCP> <433@oakhill.UUCP> <589@intelca.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 42
Xref: watmath net.arch:1282 net.lang.c:5324 net.micro:10585 net.micro.pc:4087 net.micro.68k:837

> As for "getting by", I assume you consider it a feature that your
> compiler drags along an extra 16 bits when you don't need it. When I need
> long ints, I use long ints. How do define 16 bit numbers? short? and if
> so what is a byte in your compiler?

Two points:

1) Not all 68000 C implementations have 32-bit "int"s.  You do have
to take more care to be more type-correct when writing code.  I consider
this a feature, not a bug...

2) Well, the C compiler on the 68000-based UNIX machine this is being typed
on supports 32-bit "int"s and defines 16-bit numbers as "short" and a byte
is 8 bits - it can be called "char" or "unsigned char" depending on whether
you want sign extension.  What's so hard about defining 16-bit numbers on
32-bit "int" implementations of C?  The VAX has done it for quite a few
years now.

3) 16-bit "int"s on machines with large address spaces can make it a pain to
deal with large lumps of data.  For instance, the V7/S3 "nm" loses big,
because it uses "realloc" to grow its in-core copy of the symbol table.
"realloc" takes an "unsigned int" as its argument; get more than 64KB worth
of symbol table and you lose (yes, there do exist programs which break
this).  Unfortunately, C doesn't have a way of saying "int big enough to
hold the size of the address space, in bytes" nor is there any standard system
include file defining such a type.

> Here we are discussing compilers again, Microsoft has yet to release a
> compiler that can deal with large arrays, the 286 has a 1Gbyte virtual
> address space and hence plenty of room.  I personally can write the
> "benchmark" in assembly quite easily, again the COMPILER can't hack it
> but the chip can.

Why is it so hard to write compilers which can handle that 1GB virtual
address space?  It's much easier on the 68000.  How easy is it to write a
compiler which can handle 65,537-byte arrays almost as efficiently as it
handles 65,536-byte arrays?  (For that matter, how easy is it to handle
128KB contiguous arrays of bytes, e.g. the screen that what I'm typing
is appearing on?)  The compiler may have trouble hacking it because the chip
makes it difficult to handle.

	Guy Harris