hjelm@g.gp.cs.cmu.edu (Mark Hjelm) (03/16/91)
Since the world's not quite all a 32-bit workstation (formerly "Vax"), I would be interested in generating a list of the characteristics of other architectures as related to supporting C. My interest is for writing portable programs and supporting distributed programs in heterogeneous computing environments. I would like descriptions of various alternative architectures, as well as descriptions of how the C compilers deal with them. Topics of interest include: integer sizes (e.g. sizeof(int)!=32, sizeof(long)>32, long long) integer formats (not 2's complement) float formats (not ieee, vax) multiple pointer formats segmented architectures word-oriented architectures capability architectures anything with non-standard function pointer formats alignment constraints bitfield implementations argument passing mechanisms stacks alloca implementations upward growing multiple register sets (e.g. register windows) whatever else Please send email, and I will summarize the responses. Thanks, Mark hjelm@cs.cmu.edu
hjelm@g.gp.cs.cmu.edu (Mark Hjelm) (03/17/91)
I should clarify: I am well aware of what the Ansi standard says about portable programs. As an implementor of tools supporting heterogeneous distributed computing, I am interested in specific machines that have (or could have) "interesting" C implementations. I would like to produce a list of such machines so that I can plan ahead in my implementation-level code and recognize the machines when I hear their name. Thanks again, Mark hjelm@cs.cmu.edu
gwyn@smoke.brl.mil (Doug Gwyn) (03/17/91)
In article <12374@pt.cs.cmu.edu> hjelm@g.gp.cs.cmu.edu (Mark Hjelm) writes: >Since the world's not quite all a 32-bit workstation (formerly "Vax"), >I would be interested in generating a list of the characteristics of >other architectures as related to supporting C. My interest is for >writing portable programs and supporting distributed programs in >heterogeneous computing environments. I would like descriptions of >various alternative architectures, as well as descriptions of how the >C compilers deal with them. Topics of interest include: ... This is the wrong approach if you're truly interested in developing portable C code. Simply take it for granted that there are a wide variety of computer architectures, and avoid relying on architecture. The C standard spells out the constraints that must be followed by a strictly conforming program; follow them carefully and you should have no problems with the diversity of computer architectures.
gwyn@smoke.brl.mil (Doug Gwyn) (03/17/91)
In article <12375@pt.cs.cmu.edu> hjelm@g.gp.cs.cmu.edu (Mark Hjelm) writes: >I should clarify: I am well aware of what the Ansi standard says >about portable programs. As an implementor of tools supporting >heterogeneous distributed computing, I am interested in specific >machines that have (or could have) "interesting" C implementations. I >would like to produce a list of such machines so that I can plan ahead >in my implementation-level code and recognize the machines when I hear >their name. Essentially ALL present-day computer systems are capable of supporting conforming implementations of C. Rather than trying to catalog lists of specific system names, which would become quickly obsolete anyway, you're much better off having the code automatically adjust to the particular environment by reacting to properties of the environment. For example, the MUVES "Dx" package supports data interchange between heterogeneous architectures, but it automatically configures itself (a) at compile time, using preprocessor arithmetic tests, and (b) at run time, by exchanging test data between the systems when a connection is established. Method (a) can in theory be problematic, but in practice is a fairly reliable method of determining certain properties of the host architecture. Method (b) is foolproof if you code it carefully.