bs@alice.UucP (Bjarne Stroustrup) (02/15/86)
> From: page@ulowell.UUCP (Bob Page) > Newsgroups: net.lang.c++ > Subject: Non-SysV versions > Date: Fri, 14-Feb-86 11:33:58 EST > Organization: University of Lowell > I've just ordered c++ from AT&T, for SV (of course). I don't run SysV; Really, so why did you order the SysV version? Seriously, though, the standard distribution tape has a BSD version on it. Just say ``make'' in the bsd directory and it makes itself on a BSD. Did you notice that you can ask for either a cpio tape or a tar tape? The only difference between SysV and BSD for the translator is that the Berkeley people has a slightly different stdio.h. The translator depends only on <stdio.h> and <ctype.h>. This typically makes porting trivial. Actually, I work on an 8th Edition, so the C++ translator couldn't depend on specific features particular to either SysV or BSD. The translator comes with a full set of header files for SysV (but not with a full set for BSD). > I intend to port it to 4.[23]BSD, Ultrix-32 V1.[012] and DG/UX (a SysV > lookalike with nearly full 4.2BSD libraries too). Don't worry too much about porting C++. I it quite easy once you get used to it. Just compile the translator C++ source into (intermediate) C for the target machine. For that you use the -I option to supply standard headers for the target system and +x to supply size and alignment information for the target system. You then compile the resulting C on the target system and it ought to work. Often it does not because of mistakes you make or because of bugs in the target machine's C compiler. For example, the Apollo compiler can/could not handle switch (i) { int a; // <*** the problem case 1: ... }; so you have to move the declaration of "a" in the intermediate C code. (this C compiler bug were reported to Apollo 3 years ago). Another example: the Sun C compiler used not to accept constructs like ``(int) a/2''. The cast was the problem. A nastier class of problem occurs when you get the size/align file wrong. Maybe someone could post ``good'' size/align files for machines on the net? A reminder: You need a machine with near a megabyte of memory to have the translator translate itself without modification. You need a C compiler that handles structure assignment, and a linker that supports long names (you can live with 31 characters, but more is better). You need a system that provides a stdio.h. > Thanks - > > ..Bob > -- > UUCP: wanginst!ulowell!page Bob Page > ARPA: page@ulowell.CSNET U of Lowell CS Dept > VOX: +1 617 452 5000 x2233 Lowell MA 01854 USA - Bjarne Stroustrup (AT&T Bell Labs, Murray Hill)
pallas@Navajo.ARPA (Joseph Pallas) (02/17/86)
With respect to size/align files, I wrote this little bit of code in C
that generates some (but not all) of the required information. Can anyone
tell me why the compiler wants some of the more obscure stuff, and how I
can figure it out at runtime in a C program?
/* alignments tester */
struct c { char c1; char c2;};
struct s { char c; short s;};
struct i { char c; int i;};
struct l { char c; long l;};
struct f { char c; float f;};
struct d { char c; double d;};
struct ch { char c;};
struct st { char c; struct ch sc;};
struct wp { char c; int *wp;};
struct bp { char c; char *bp;};
#define CHECK(name,type,struc) printf("%s %d %d\n",\
name, sizeof(type), sizeof(struc) - sizeof(type))
main()
{
CHECK("char", char, struct c);
CHECK("short", short, struct s);
CHECK("int", int, struct i);
CHECK("long", long, struct l);
CHECK("float", float, struct f);
CHECK("double", double, struct d);
CHECK("struct", struct ch, struct st);
CHECK("wptr", int *, struct wp);
CHECK("bptr", char *, struct bp);
}
---
Joe Pallas
...decwrl!glacier!navajo!pallas
pallas@navajo.stanford.edubs@alice.UucP (Bjarne Stroustrup) (02/18/86)
> From: pallas@Navajo.ARPA (Joseph Pallas) > Newsgroups: net.lang.c++ > Subject: Re: porting C++ > Organization: Stanford University > > Can anyone tell me why the compiler wants some of the more obscure stuff, > and how I can figure it out at runtime in a C program? Most of the alignment stuff is needed to allow the compiler to calculate sizeofs. Consider this beauty: struct s { int a: 4; }; int v[ sizeof(struct s) ]; What is the size of struct s? Well, that depends. On some machines every struct has a minimal size so the answer is something like sizeof(char*). On other machines the minimal space set aside for a field is sizeof(int). On the other hand there are machines/C-compilers that use only sizeof(char) for struct s. This is the minimum size since a char is defined to be the smallest unit of memory that can be independently allocated. There are also machines where sizeof(struct s)==sizeof(int), but where struct ss { char a : 4; }; implies sizeof(struct ss)==sizeof(char). Obscure, yes. Perverse, maybe. But it has to be right to preserve C link-compatibility. I don't know any fully portable way of finding all the information needed (remember this must be done in such a way that it circumvent ``inessential'' C compiler bugs and restrictions). Every time I think I have it, someone comes along with a C compiler with a new twist. C, and therefore C++, says that the type of an integer constant is int unless the value is larger than the largest integer in which case the type is long. Consequently a C++ compiler must know what the largest int is. Here is one way of getting that value in C on a two's complement machine: int largest = ((unsigned)~0)>>1; - Bjarne Stroustrup (AT&T Bell Labs, Murray Hill)