peter@ficc.UUCP (Peter da Silva) (08/15/88)
In article <6104@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: > In article ... davidsen@crdos1.UUCP (bill davidsen) writes: > >I would really like to see a "packed struct," also. This would be a > >struct packed on byte boundaries without fill, no matter *how bad* the > >code was to use them. > Consider the following code: > packed struct { char c; int i; } x; > int *p = &x.i; ^^^^^^^^^^^^^ This should be illegal. > *p = 0; It is already illegal to take the address of one object with no legal address... a register variable. Why should it be legal to take the address of a misaligned integer? Another comment: what about: packed struct { int a:1; int b; int c:17; } argh; -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/17/88)
In article <1258@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: | In article <6104@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: | > In article ... davidsen@crdos1.UUCP (bill davidsen) writes: | > >I would really like to see a "packed struct," also. This would be a | > >struct packed on byte boundaries without fill, no matter *how bad* the | > >code was to use them. | It is already illegal to take the address of one object with no legal | address... a register variable. Why should it be legal to take the address | of a misaligned integer? Thank you for a good solution to the problem to pointers. Obviously if this was added it would have to be illegal on all machines, not just those which couldn't hack the addressing. | Another comment: what about: | | packed struct { int a:1; int b; int c:17; } argh; Yes, I was careful to say byte alligned for this reason, but I may not have discussed the rationale. Bit alligned is so rarely useful that I can see no reason for adding it to the language. Byte alligned is nice for passing data between machines, such as computers and control equipment. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
chris@mimsy.UUCP (Chris Torek) (08/17/88)
In article <11868@steinmetz.ge.com> davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > Yes, I was careful to say byte alligned for this reason, but I may >not have discussed the rationale. Bit alligned is so rarely useful that >I can see no reason for adding it to the language. Byte alligned is >nice for passing data between machines, such as computers and control >equipment. Hmm: `Bit aligned is nice for passing data between machines, such as 18-bit computers and 32-bit control equipment' :-)? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
lee@ssc-vax.UUCP (Lee Carver) (08/17/88)
In article ... davidsen@crdos1.UUCP (bill davidsen) writes: > I would really like to see a "packed struct," also. This would be a > struct packed on byte boundaries without fill, no matter *how bad* the > code was to use them. In article <1258@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: > ... how about .. > packed struct { int a:1; int b; int c:17; } argh; Why should packing be constrained to byte boundarys. Why not any 'type' boundary? Sure, some elements might not have addresses, but the code is probably machine/application dependent any. Invariably packed structures are. So how about packed [ type-specifier ] [ structure-specifier ] The elements of the structure-specifier are aligned to type-specifier boundaries. Maybe default to byte if an empty type- specifier is used? Allow the type specifer to be anything, even other structures. Then, some proposals might be represented as: packed short struct { char a; long b; char c; } blix; and for wierdness packed structure blix struct { float b; char *d;} blax;
karl@haddock.ima.isc.com (Karl Heuer) (08/19/88)
In article <8186@cup.portal.com> thad@cup.portal.com writes: >Constructs such as the following do NOT function "properly" with most >compilers: > struct OneBitElement { int foo : 1; }; > struct MyDataBlock { struct OneBitElement bletch[32]; }; As a consequence of the sizeof() rules, I don't think it could function "properly" on *any* C compiler. (I think the sizeof(char)==1 rule should have been deprecated, but X3J11 says it's too late to change it now.) Your "bit" extensions seem useful, but unfortunately they don't fit in very well with the rest of the language. In particular, the automatic mapping of arrays to pointers makes it hard to handle bit arrays. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
thad@cup.portal.com (08/29/88)
But, the machine for which I *NEEDED* that capability (DECSYSTEM-20) does have pointers to bits (bits of any size from 1 to 36 bits). I also needed needed the equivalent of "packed structures" (and implemented that, too). The original "program" comprised some 1,000,000 lines of assembly code of which I did approx. 50% (parsers, code gen, runtime, etc.). 3 years ago began the re-implementation in C (to ease porting to other architectures), but approx. 25% of the DEC-20 implementation remains in assembly with which the new C code must co-exist (esp. data structures). For the VAX and 68020 implementations, nearly all bit fields (AND unions) have been removed. The discussion re: packed structures earlier in this newsgroup brings home a requirement that sometimes storage efficiency "weighs more" than does processing efficiency. Some of my clients have databases (processed using my product) exceeding 100,000,000 "records"; for them, storage efficiency is critical (also reduces I/O bandwidth). Having the sources to the compiler was a lifesaver; was able to timely and cost-effectively solve a real problem (fully realizing the non-portability of my solution).
boyne@hplvli.HP.COM (@Art Boyne) (09/06/88)
mouse@mcgill-vision.UUCP (der Mouse) writes: > By the way, does anyone know of a non-mechanical digital calculator or > computer that isn't essentially binary? If you allow antiques, the old IBM 1620 was a decimal CADET (can't add, doesn't even try) machine doing add/subtract via tables located in low core. Art Boyne, !hplabs!hplvly!boyne