🚀 go-pugleaf

In article <43mie5$ipl@post.gsfc.nasa.gov> Mike Stark,
michael.e.stark@gsfc.nasa.gov writes:
>>For some reason, portability has come to mean, "Hide all knowledge of the
>>bit-and-byte level." This is a bit of a fallacy, as you are really trying
>>to hide the effects of the machine archtecture. Bits-and-bytes are really
>>abstract concepts, independent of architecture, and shouldn't be hidden.
>>Probably it most hits the road when you consider element alignment within
>>a structure. Even there you probably want and need to know such things
>>for performance reasons, as well as be able to read structures that are
>>stored in binary form in files.
>

It is not just persistent data in files that is important.  System
level software in many cases read and write data structures. 
Interfaces are published in "C" header files, or possibly another
language.  Compiler vendors can not supply all the interfaces
which may be needed by all programmers.  If you are foolish enough
to want to use a better language you are stuck hand translating
the interface unless there is a translator.  

I am in the process of translating the Xlib interface for XFree86
under linux for the Garden's Point Modula-2 (gpm) compiler.  After
this I may start with Xt intrinsics.  I would love a C-to-Modula
translator which would help with this, maybe a later project.

The point is not that I have to do this manually, but rather that
the implementation of the concrete layout is hidden.  Luckly the
people who made gpm have worked very hard to make this easy by
using the same layout stategy as the gnu cc compiler.  

IMHO if a data structure is ever to be exported (not in the M2
sense) outside the application either in persistent storage,
network protocols, or as inputs/outputs to system library routines
then the size of the data  should be specifed concretely. 
INTEGER8, INTEGER16, INTEGER32, INTEGER64, INTEGER128 are good,
whereas INTEGER, and "int" are bad for portability of data
structures across machines, and languages, or even compilers
implementing the same language (see amiga example below).  

This is not to say that INTEGER, CARDINAL should never be used,
they  are fine as long as they are internal to the application.   

In article <43oel3$qsk@nntp.nta.no> Ole-Hjalmar Kristensen TF.E/DELAB,
ohk@hal.nta.no writes:
>|> 
>|> Aside from that I still disagree with you:  a programming language
>|> should not specify low-level things like memory layout in its
>|> definition.  Most of the time you don't need that kind of knowledge,
>
>If it is a systems programming language, I think it should.

Agreed explicity specifying the size of primitive data types in the
interfaces between the operating system, or system level libraries,
and any client software is required.  Leaving anything implicit in
these interfaces is bad design.  

The Amiga software community had a problem for a short time, because
the two major C compilers defined "int" differently.  One defined it
as 16 bits, and the other as 32.  A number of header files used "int"
in the interfaces.  Those interfaces were quicky (?) updated to 
define arguments explicitly using "typedef unsigned short int USHORT" 
and the like.  (Sorry if the C syntax is wrong, I don't do "C", nor
do I do drugs).  This applies not only to persistent data, but also
to arguments to OS calls, and system libraries (ex. Xlib).

Shortly we will have compilers where the "int" will be a 64-bit word.
Then in many cases we will have the same problem we had when we went 
from 16-bit words to 32.

>|> As many others have pointed out already, if you really need to do I/O
>|> with specific memory layouts, then it is usually very easy to write
>|> I/O subroutines explicitly and encapsulate that code in a few
>|> functions.  So you never worry about it no matter what the compiler
>|> decides to do.

Is calling Xlib, to define a window, an I/O operation?  File I/O is
just one example of imports and exports of data to an application or
system library.

True, file I/O can be encapsulated when the format is well defined,
but if a data structure stored in a file is not well defined then I
will be out of luck.   Marginal documentation may say the type of
data, but not the size or the endian order.  You will need to
experiment to get you encapsulation routine to work right.  There
is nothing new in that, but it helps immensely if you start with
the right size primitive data types.

With a 64-bit computer the INTEGER is located in a 64-bit word,
which is larger than the LONGINT on most computers of today.  
Future 64-bit computers will be in the workplace in 2 years (today
if you get an Alpha from Digital), and in 10 years for your home. 
Programs will need to be able to read persistent data from
secondary storage, and communinicate with the old computers which 
will still on the network.  

Of course, In ten years, I will need such big words to address the
4+ tera-byte (4+ * 2^40) hologram crystal secondary storage
facility which will replace my home computer's 500 mega-byte hard
disk.  A 32-bit word can only address 4 giga-bytes (4 * 2^30).  Of
course you can say that the file system does not need to address
bytes, but only needs to address blocks. Then I will wait another
10 years for a sub-quanta interspatial resonent storage chamber
(2*120 bytes) whatever that is.  The  point being that secondary
storage will always be getting dramatically bigger.  Five years
ago, I would never have thought that I would be able to buy a 1.2
giga-byte drive for $300.

....................................................................
: Peter "Eyes" Eiserloh
: None of the opinions expressed here are in any way related those 
: of my employer.
: Keywords: Linux, Modula-2, Compilers, Esperanto, Physics