Related articles |
---|
[8 earlier articles] |
Re: Help: How to determine big/little endian? meissner@cygnus.com (Michael Meissner) (1995-08-25) |
Re: Help: How to determine big/little endian? cwf@research.att.com (Chris Fraser) (1995-08-25) |
Re: Help: How to determine big/little endian? nr@cs.purdue.edu (1995-08-25) |
Re: Help: How to determine big/little endian? doug@netcom.com (1995-08-26) |
Re: Help: How to determine big/little endian? meissner@cygnus.com (Michael Meissner) (1995-09-01) |
Re: Help: How to determine big/little endian? mab@wdl.loral.com (1995-09-01) |
Re: Help: How to determine big/little endian? erik@kroete2.freinet.de (1995-09-03) |
Re: Help: How to determine big/little endian? daniels@cse.ogi.edu (1995-09-13) |
Re: Help: How to determine big/little endian? wdavis@dw3f.ess.harris.com (1995-09-26) |
Newsgroups: | comp.arch,comp.compilers |
From: | erik@kroete2.freinet.de (Erik Corry) |
Keywords: | architecture, design |
Organization: | Home |
References: | <4074ig$nh7@masala.cc.uh.edu> 95-08-182 95-09-011 |
Date: | Sun, 3 Sep 1995 23:49:08 GMT |
Norman Ramsey (nr@cs.purdue.edu) wrote:
: I love disk and network formats that have fixed byte orders.
: Down with the X protocol!
Since a lot of X-protocol traffic is local it would make very little
sense to have a fixed network byte order for X. The overhead would be
very unfair on half the machines. (Or was that a joke?)
I find it a little tiring that the request for simple endianism
macros is always greeted by shouts of "you don't need it" and "some
machines don't have a clear endianism". The ANSI comittee recognised
that many things that aren't essential can be useful when they
defined the contents of limits.h. Many of the things you'll find
there, like the number of bits in a char and the largest
representable float could be worked around, but there's no need. Even
the sizeof operator isn't strictly necessary: you could easily
determine the sizeof a type at runtime with a small array. And the
machines without a clear endianism are a) very rare, and b) not
inconvenienced by a solution that helps everyone else.
I write graphics software, and there are many cases where it is gives
a performance advantage to access the same data by bytes and by
longwords depending on the algorithm being used. Sure, I could
provide two versions of the relevant functions, one for each
endiansim, but I don't really enjoy having to fix all bugs in two
different places etc. It really wouldn't cost much to have these
macros available, but the suggestion is always dismissed by those who
don't need it.
--
Erik Corry ehcorry@inet.uni-c.dk
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.