Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!actnyc!djs
From: djs@actnyc.UUCP (Dave Seward)
Newsgroups: comp.arch
Subject: Re: Software Distribution
Message-ID: <1044@actnyc.UUCP>
Date: 6 Oct 88 22:05:58 GMT
References: <978@esunix.UUCP> <1988Sep29.192410.246@utzoo.uucp>
Reply-To: djs@actnyc.UUCP (Dave Seward)
Organization: InterACT Corporation
Lines: 33

In article <1988Sep29.192410.246@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>ranges in anything in my author_copy file. What I keep saying is that
>>the compiler must explicitly state its ASSUMPTIONS in the UIF form of
>>a program...
>
>How does the target machine's translator know whether it can do the
>arithmetic that the program wants?  This cannot be stated in the UIF
>unless the compiler can figure it out.

Or unless the programmer has a way of informing the compiler. My take is
that it is not worth supporting the likes of *NULL == NULL if it can't
be done effectively on all target machines, but the concept of the programmer
stating his assumptions about each of a class of variably implemented
features (arithmetic bit sizes, value of *NULL, et al) is a valuable one,
and puts the onus on the programmer, who in this case knows explicitly 
that he is writing supposedly portable code. Safe or reasonable values
can be assumed for these variable features, and the code generator for
each target can warn about cases where it can't implement the desired
option, or can't do it efficiently. It may even be reasonable for the format
to contain different code (provided by the programmer) for specific critical
sections, one for each variant of a variably defined feature, allowing the
most efficient use of each kind of machine (for that feature). The code
generator would then select the appropriate one for the target machine.

An additional thought about correctness: such a portable program should be
delivered with a set of verification tests so that one doesn't have to find
out with one's own data and effort that the program has a machine dependency
in it that prevents it from working (for some feature) on your machine. This
would quickly be enforced by market dynamics after 1) several people get
burned by broken programs, and 2) some vendors start to deliver test suites.

Dave Seward
uunet!actnyc!djs