Re: Porting Experiences (was Ada and Pascal etc )

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote:
>Jon S Anthony wrote:
>> 
>> Craig Franck <clfranck@worldnet.att.net> writes:
>> 
>> > Jon S Anthony <jsa@synquiry.com> wrote:
>>
>> > >That rings true as well.  Typically porting Ada code between platforms
>> > >or compilers amounts to a recompilation.
>> >
>> > Something like a Windows to Mac port? How platform specific was the
>> > code? A recompilation port would be the ideal we all chase after. If
>> > you have such great splatfrom tools, you should feel lucky.
>> 
>> I've not had any need (or opportunity) to port to Mac.  The code in
>> question went between VMS (VAX&Alpha), Sparc Solaris, Sparc SunOS,
>> HP-UX, Intel Win/NT and across three different compilers.
>> 
>> One was about 60K lines with lots of generics and tasks.
>> 
>> Another was around 200K lines with lots of (goofy use) of generics.
>> 
>> No #ifdefs stuff anywhere in site.
>
>If that's C code you're talking about, I'm radically impressed.
>If that's C++ code, then you're qualified to walk on water, or more
>likely you're a purveyor of Tall Stories.
>If that's Ada, then it's par for the course.

What is it about Ada that makes it portable? I would say it is the
types of applications being developed, as well as the platforms,
and, perhaps, quality of implementation. Last time I was in Barnes 
& Noble I saw "Ada 95 for C and C++ Programmers" by Simon Johnston,
from Add-Wes. I almost got it because it had a compiler from Aonix
called "Objective Ada for Windows" on the accompanying CD. It would
be interesting to see what that would be like. I just do not see
how once I start throwing windows up on the screen and responding
to messages, that that code is porting anywhere.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Alan E & Carmel J Brain]

Jon S Anthony wrote:
> 
> Craig Franck <clfranck@worldnet.att.net> writes:
> 
> > Jon S Anthony <jsa@synquiry.com> wrote:
>
> > >That rings true as well.  Typically porting Ada code between platforms
> > >or compilers amounts to a recompilation.
> >
> > Something like a Windows to Mac port? How platform specific was the
> > code? A recompilation port would be the ideal we all chase after. If
> > you have such great splatfrom tools, you should feel lucky.
> 
> I've not had any need (or opportunity) to port to Mac.  The code in
> question went between VMS (VAX&Alpha), Sparc Solaris, Sparc SunOS,
> HP-UX, Intel Win/NT and across three different compilers.
> 
> One was about 60K lines with lots of generics and tasks.
> 
> Another was around 200K lines with lots of (goofy use) of generics.
> 
> No #ifdefs stuff anywhere in site.

If that's C code you're talking about, I'm radically impressed.
If that's C++ code, then you're qualified to walk on water, or more
likely you're a purveyor of Tall Stories.
If that's Ada, then it's par for the course.
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Porting Experiences (was Ada and Pascal etc )

[Jon S Anthony]

Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes:

> Jon S Anthony wrote:
> > 
> > Craig Franck <clfranck@worldnet.att.net> writes:
> > 
> > > Jon S Anthony <jsa@synquiry.com> wrote:
> >
> > > >That rings true as well.  Typically porting Ada code between platforms
> > > >or compilers amounts to a recompilation.
> > >
> > > Something like a Windows to Mac port? How platform specific was the
> > > code? A recompilation port would be the ideal we all chase after. If
> > > you have such great splatfrom tools, you should feel lucky.
> > 
> > I've not had any need (or opportunity) to port to Mac.  The code in
> > question went between VMS (VAX&Alpha), Sparc Solaris, Sparc SunOS,
> > HP-UX, Intel Win/NT and across three different compilers.
> > 
> > One was about 60K lines with lots of generics and tasks.
> > 
> > Another was around 200K lines with lots of (goofy use) of generics.
> > 
> > No #ifdefs stuff anywhere in site.
> 
> If that's C code you're talking about, I'm radically impressed.

Of _course_ it's not C code, :-).  Check the context again: It refers to
Ada code.

> If that's C++ code, then you're qualified to walk on water, or more
> likely you're a purveyor of Tall Stories.

Exactly.  Actually, come to think of it, I don't even think being God
would help much...


> If that's Ada, then it's par for the course.

It's Ada code as the context confirms.

/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Porting Experiences (was Ada and Pascal etc )

[Alan E & Carmel J Brain]

Craig Franck wrote:

> What is it about Ada that makes it portable? I would say it is the
> types of applications being developed, as well as the platforms,
> and, perhaps, quality of implementation.

You may have a point: A language that has the capability to make a a
well-defined interface, ie a language encouraging components, may well
mean that the type of applications it's used for are, by their very
nature, 'portable-friendly'.
OTOH Embedded systems, avionics, air etc don't strike me as being more
inherently 'similar' to one another as, for example, spreadsheets or
operating systems. Any evidence on this one?

> I just do not see
> how once I start throwing windows up on the screen and responding
> to messages, that that code is porting anywhere.

OK, so GUIs vary. My point is that even in two implementations where the
GUI is isolated/wrapped and so not "part of the problem", that
portability with C++ (forex) is considerably less than great.


> Last time I was in Barnes
> & Noble I saw "Ada 95 for C and C++ Programmers" by Simon Johnston,
> from Add-Wes. I almost got it because it had a compiler from Aonix
> called "Objective Ada for Windows" on the accompanying CD. It would
> be interesting to see what that would be like. 

I can recommend it. Have a look at http://www.adahome.com/ which has a
link to an pre-publication version/extract from it.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Porting Experiences (was Ada and Pascal etc )

[Jon S Anthony]

Craig Franck <clfranck@worldnet.att.net> writes:

> What is it about Ada that makes it portable? I would say it is the
> types of applications being developed, as well as the platforms,
> and, perhaps, quality of implementation.

I'm not sure that the types of applications or platforms have much to
do with it.  Quality of implementations, yes, sure.  However, I'd say
that the major reasons for portability are:

a) A pretty darn tight and precise standard.

b) Few "implementation defined" areas in that standard which are
visible to the programmer's model.

Makes a _HUGE_ difference.

/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Craig Franck wrote:
 
> What is it about Ada that makes it portable? 

How about the ability to define variables by their range instead of
using implimentation-dependent terms like long and short? That's
certainly the most glaring deficiency in C with regard to portability.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <345E3ACD.A15@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
>Craig Franck wrote:
> 
>> What is it about Ada that makes it portable? 
>
>How about the ability to define variables by their range instead of
>using implimentation-dependent terms like long and short? That's
>certainly the most glaring deficiency in C with regard to portability.

That depends on how you look at it. I'd say that it requires a little
more thought and skill to write portably with types that have sizes
that are not fully specified, but it's not impossible.

C gives you a header, <limits.h>, which gives you the constants LONG_MIN
and LONG_MAX. These tell you what the implementation's least and
greatest values of type long are. These values are guaranteed to be
at least -2^31+1 and 2^31-1 respectively.

If you assume that the long type has a range that is no larger than this,
you are OK. If you write your code under the assumption that the
range is LONG_MIN to LONG_MAX, you are also OK.

Sure, you might not be able to declare subtypes with more restricted ranges
like in Ada, but that doesn't mean that portability has gone out the window!
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Marin David Condic, 561.796.8997, M/S 731-96]

Craig Franck <clfranck@WORLDNET.ATT.NET> writes:
>What is it about Ada that makes it portable? I would say it is the
>types of applications being developed, as well as the platforms,
>and, perhaps, quality of implementation. Last time I was in Barnes
>& Noble I saw "Ada 95 for C and C++ Programmers" by Simon Johnston,
>from Add-Wes. I almost got it because it had a compiler from Aonix
>called "Objective Ada for Windows" on the accompanying CD. It would
>be interesting to see what that would be like. I just do not see
>how once I start throwing windows up on the screen and responding
>to messages, that that code is porting anywhere.
>
    I'd agree with the assessment about putting windows up on a
    screen. The only way this *might* be considered portable is that,
    for example, WinNT runs on more platforms than Pentium boxes, so
    sticking to the Win32api, your code will port. No such luck if you
    try to take it to a Motif box.

    I've had lots of success porting Ada code both from Ada83
    compilers to Ada95 compilers, between different vendors compilers
    for the same hardware and between dramatically different machine
    architectures. (Embedded M680x0 to Sun Unix & similar) Since I'm
    dealing primarily with embedded application code that does no I/O
    of its own, the ports have been very successful and mostly
    painless. (I had to modify some packages that had embedded
    assembler statements and eliminate a couple of calls to some
    vendor supplied code and that was about it.) Its always the I/O
    that gets you on a port because that's where the language has to
    interface to things beyond its control. Even with Text_IO as your
    only interface, you'll find variations in behavior across
    platforms - even with the same compiler vendor. (I've found some
    variance using GNAT between Sun/Unix and Pentium/WinNT concerning
    terminal I/O behavior and GNAT is a perfectly fine example of
    portable compiler technology.)

    I don't know that there will ever be a good answer to this issue.
    Certainly this is not a problem peculiar to Ada - C, C++, et alia
    are all going to be plagued with the same troubles so it would not
    be fair to say "Ada sucks because when I program I/O code, it
    doesn't port from Sun/Unix/Motif to IBM-370/MVS/Punchcards..." Yet
    all too often Ada (and other languages) are attacked for
    completely silly reasons - usually by inexperienced students who
    have not yet learned much about computers, operating systems and
    programming languages.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
===============================================================================
    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."
        --  G.K. Chesterton
===============================================================================

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <01bce929$4a8cbe80$560b6dce@my-pc.neosoft.com>,
Pat Rogers <progers@acm.org> wrote:
>Kaz Kylheku <kaz@helios.crest.nt.com> wrote in article
><63mcmm$r3s$1@helios.crest.nt.com>...
>> In article <345E3ACD.A15@gsg.eds.com>,
>> Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
>> >Craig Franck wrote:
>> > 
>> >> What is it about Ada that makes it portable? 
>> >
>> >How about the ability to define variables by their range instead of
>> >using implimentation-dependent terms like long and short? That's
>> >certainly the most glaring deficiency in C with regard to portability.
>> 
>> That depends on how you look at it. I'd say that it requires a little
>> more thought and skill to write portably with types that have sizes
>> that are not fully specified, but it's not impossible.
>> 
>> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
>> and LONG_MAX. These tell you what the implementation's least and
>> greatest values of type long are. These values are guaranteed to be
>> at least -2^31+1 and 2^31-1 respectively.
>> 
>> If you assume that the long type has a range that is no larger than this,
>> you are OK. If you write your code under the assumption that the
>> range is LONG_MIN to LONG_MAX, you are also OK.
>
>That's missing the point.  By having application-specific ranges for
>integers and accuracy for floating point types, an Ada programmer finds out
>*at compile time* that their new target cannot handle the program they are
>porting. 

But then the program is not portable. You are no longer talking about 
portable programming. Your Ada program has failed to translate for a
target for which a conforming Ada implementation exists. It is therefore
not a portable Ada program.

I'm talking about writing programs that work anywhere, for which it is not
acceptable to fail to translate. I don't think that I'm missing the point.

What if you _have_ to get that program running on that target? You have
some revising to do, in effect creating a new variant of that program
which is more portable.

In C you can also write programs that fail to translate depending on the
capabilities of the target. E.g.

    #include <limits.h>

    #if CHAR_BIT != 9
    #error require a 9 bit char
    #endif

but this sort of thing isn't of particular interest to programmers who keep
utmost portability in mind. It's not an acceptable answer to issues of
portability.

>Sure, we can all play with assuming what the portable ranges are,
>but compile-time checking finds them earlier and thereby cheaper, than

In C, the portable ranges are given to you by the standard, so there is no need
to find them at compile time. 

>hopefully having users detecting a bug.  In Ada, we know predefined Integer
>is at least 16 bits, but best approach is to avoid it when possible, since
>the more portable alternative is available.

What is the more portable alternative? To declare a type that has the specific
range -32767 to 32767? This has some clear advantages over using plain Integer,
but I don't see portability as being one of them. Or are you worried about some
implementation of Ada which only gives you a 15 bit Integer? Would that
not be a non-conforming implementation?
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Kaz Kylheku wrote:
> 
> That depends on how you look at it. I'd say that it requires a little
> more thought and skill to write portably with types that have sizes
> that are not fully specified, but it's not impossible.
> 
> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
> and LONG_MAX. These tell you what the implementation's least and
> greatest values of type long are. These values are guaranteed to be
> at least -2^31+1 and 2^31-1 respectively.
> 
> If you assume that the long type has a range that is no larger than this,
> you are OK. If you write your code under the assumption that the
> range is LONG_MIN to LONG_MAX, you are also OK.
> 
> Sure, you might not be able to declare subtypes with more restricted ranges
> like in Ada, but that doesn't mean that portability has gone out the window!

So the portable way to declare 33-bit integers is to declare them as
long and let them be 128 bits on some machines? I don't consider that a
viable option. To restate, there is no portable way to cause the
compiler to chose a size that is the best compromise between the problem
requirements and the natural byte sizes of the machine.

In Ada I give a range of values and the compiler figures out whether to
use, e.g., words, half words or double words. In PL/I I give a number of
bits (for binary) or a number of digits (for decimal) and the compiler
figures it out. In C I have to play games with, e.g., multiple versions
of my headers. Unless and until the new standard passes, this aspect of
C will remain a serious blot on the claims of portability.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Craig Franck wrote:
 
> That was mentioned in an several e-mails I received. 

Since I last posted I saw an article stating that the next C standard
will include a way to specify the required precision. That will be a
welcome change!

> It seems you can define the interface with the machine in Ada; in
> C, what you would do is keep the values in the portable range as
> defined by the standard. This isn't as bad as it would seeem. If
> an implementation decides 64-bit ints are the best representation,
> a short, int, and long could all be 64-bits. Portable software just
> wouldn't exceed 32,767 for an int.

Which is the same situation that we had when C first emrged, except that
8-bit processors are no longer an issue. If I need more than 32 bits,
how fo I declare it without getting 128 bits on some machines? With Ada
or PL/I the issue doesn't arise.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Lawrence Kirby wrote:
> 
> The portability implications of this are small or non-existent (there may
> be performace implications in rare circumstances, and issues relating to
> data sizes and external data formats). As ever the C language is designed
> with the assumption that the programmer knows what he is doing. The use
> of ranges implies that you know beforehand what those ranges will be.
> In C you follow a set of rules:
> 
> 1. If the range is contained within -32767 to 32767 then you use int
> 
> 2. If the range is contained within -2147483647 to 2147483647 then you
>    use long.
> 
> 3. If you want to minimise space usage (such as for array elements or
>    structure members) and the range is contained within -32767 to 32767 then
>    you can use short. For -127 to 127 you can use signed char.
> 
> 4. The unsigned types have larger positive ranges if your range is
>    non-negative. Notably unsigned char typically corresponds to the
>    notion of "byte" in most languages.

Those rules only apply if you are going from one 32-bit machine to
another; they have nothing to do with the definition of C itself and are
inapplicable when you have to move between different word sizes.

The C standard makes the size of an int implimentation dependent, and on
16-bit machines it is normally 16. On 64-bit machines int is usually 64,
and if you want 32 you specify short.

Now, admittedly this will change with the new standard, but as long as
it is still a draft it has nothing to do with the current language.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <345F95D0.3984@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
>Kaz Kylheku wrote:
>> 
>> That depends on how you look at it. I'd say that it requires a little
>> more thought and skill to write portably with types that have sizes
>> that are not fully specified, but it's not impossible.
>> 
>> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
>> and LONG_MAX. These tell you what the implementation's least and
>> greatest values of type long are. These values are guaranteed to be
>> at least -2^31+1 and 2^31-1 respectively.
>> 
>> If you assume that the long type has a range that is no larger than this,
>> you are OK. If you write your code under the assumption that the
>> range is LONG_MIN to LONG_MAX, you are also OK.
>> 
>> Sure, you might not be able to declare subtypes with more restricted ranges
>> like in Ada, but that doesn't mean that portability has gone out the window!
>
>So the portable way to declare 33-bit integers is to declare them as

There is no portable way to declare 33 bit integers. The current ISO standard
only guarantees 32 bits for the largest integral types that C offers.

>long and let them be 128 bits on some machines? I don't consider that a
>viable option.

Why not? It might not be the _cleanest_ option, but it's certainly viable.

>To restate, there is no portable way to cause the
>compiler to chose a size that is the best compromise between the problem
>requirements and the natural byte sizes of the machine.

Sure there is. Say we are talking about a signed quantity. You first identify
the range that it shall require. If it is within -127 to 127, you may use a
char type---IF it is important for you to save storage.  Otherwise you use int.
If the range is within -32767 to 32767, you use a short if saving storage is
important. Otherwise you use int.  If the range is outside -32767 to 32767 but
within -2^32+1 to 2^32-1, you use the type long. Otherwise if you require a
larger range, you are out of luck. To stay within the limits of strictly
conforing C, you must emulate some higher precision arithmetic.

So you see, it is quite easy to choose the appropriate type for a given range
with just a few simple guidelines. Of course, it's probably a good idea to
insulate yourself using typedef alias names in case your requirements change in
the future.

>In Ada I give a range of values and the compiler figures out whether to
>use, e.g., words, half words or double words. In PL/I I give a number of

How do you express the idea that storage is to be minimized? Just because
your type requires only the range -50 to +50 doesn't necessarily mean
that you want to pack it into a single byte! Or perhaps you _do_ want to
pack it into a single byte.

>bits (for binary) or a number of digits (for decimal) and the compiler

The people who invented UNIX and C were no strangers to PL/I. :) Multics
was written in it. You know where those /* */ comments come from.

>figures it out. In C I have to play games with, e.g., multiple versions
>of my headers. Unless and until the new standard passes, this aspect of

You don't need to do any such thing if you understand the language.
I've never had to play with multiple versions of a header or #ifdef nests.

I have seen plenty of code that does just that. In each case, it was because
the author hadn't learned to use the language properly.

>C will remain a serious blot on the claims of portability.

This simply isn't true. There may be blots on that claim, but this isn't one of
them. It's an imagined problem that perhaps stems from your inexperience with
that particular language.
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <345F9728.D61@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
 >Lawrence Kirby wrote:
 >> 
 >> The portability implications of this are small or non-existent (there may
 >> be performace implications in rare circumstances, and issues relating to
 >> data sizes and external data formats). As ever the C language is designed
 >> with the assumption that the programmer knows what he is doing. The use
 >> of ranges implies that you know beforehand what those ranges will be.
 >> In C you follow a set of rules:
 >> 
 >> 1. If the range is contained within -32767 to 32767 then you use int
 >> 
 >> 2. If the range is contained within -2147483647 to 2147483647 then you
 >>    use long.
 >> 
 >> 3. If you want to minimise space usage (such as for array elements or
 >>    structure members) and the range is contained within -32767 to 32767 then
 >>    you can use short. For -127 to 127 you can use signed char.
 >> 
 >> 4. The unsigned types have larger positive ranges if your range is
 >>    non-negative. Notably unsigned char typically corresponds to the
 >>    notion of "byte" in most languages.
 >
 >Those rules only apply if you are going from one 32-bit machine to
 >another; they have nothing to do with the definition of C itself and are
 >inapplicable when you have to move between different word sizes.
 >
 >The C standard makes the size of an int implimentation dependent, and on
 >16-bit machines it is normally 16. On 64-bit machines int is usually 64,
 >and if you want 32 you specify short.

No C programmer who has a clue about portable coding would specify short
to get a 32 bit type---unless he was worried about using the smallest possible
type which fits, thus minimizing resource usage!

Note that Lawrence mentions ``performance implications'' because he knows that
if you follow the conservative rules, you might not necessarily use the
machine's resources in the best way. This is true if that machine provides data
types that have much larger ranges than what is minimally required.

If you want a type that is at least 32 bits wide, you specify long or unsigned
long. The language currently has no support for anything more. If you need 33
bits or more, there is no type which is guaranteed to satisfy. You either write
code to emulate the greater precision, or you leave the realm of portable C
coding and use some implementation-provided type like __longlong. 

A good C89 compiler for a 64+ bit platform should have a mode which flips 
longs back to 32 bits for compiling maximally portable programs that don't 
make use of the extra generosity.

Look, if you find something factually wrong in a Lawrence Kirby posting, I
shall promptly mail you a lollipop! :)
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Jerry van Dijk]

In article <97110311130668@psavax.pwfl.com> condicma@PWFL.COM writes:

>                 WinNT runs on more platforms than Pentium boxes, so
>    sticking to the Win32api, your code will port.

Well, I guess experiences vary...

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org

Re: Porting Experiences (was Ada and Pascal etc )

[Lawrence Kirby]

In article <345E3ACD.A15@gsg.eds.com> nospam@gsg.eds.com "Seymour J." writes:

>Craig Franck wrote:
> 
>> What is it about Ada that makes it portable? 
>
>How about the ability to define variables by their range instead of
>using implimentation-dependent terms like long and short? That's
>certainly the most glaring deficiency in C with regard to portability.

The portability implications of this are small or non-existent (there may
be performace implications in rare circumstances, and issues relating to
data sizes and external data formats). As ever the C language is designed
with the assumption that the programmer knows what he is doing. The use
of ranges implies that you know beforehand what those ranges will be.
In C you follow a set of rules:

1. If the range is contained within -32767 to 32767 then you use int

2. If the range is contained within -2147483647 to 2147483647 then you
   use long.

3. If you want to minimise space usage (such as for array elements or
   structure members) and the range is contained within -32767 to 32767 then
   you can use short. For -127 to 127 you can use signed char.

4. The unsigned types have larger positive ranges if your range is
   non-negative. Notably unsigned char typically corresponds to the
   notion of "byte" in most languages.

Stick to the guaranteed minimum ranges guaranteed by the standard and allow
for the ranges to be larger and there are no portability issues. This
covers the overwhelming majority of cases. C currently doesn't guarantee
anything beyond a 32 bit integer type so you will get portability issues if
you need something larger. That is a recognised problem that will be addressed
in C9X.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Pat Rogers]

Kaz Kylheku <kaz@helios.crest.nt.com> wrote in article
<63mcmm$r3s$1@helios.crest.nt.com>...
> In article <345E3ACD.A15@gsg.eds.com>,
> Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
> >Craig Franck wrote:
> > 
> >> What is it about Ada that makes it portable? 
> >
> >How about the ability to define variables by their range instead of
> >using implimentation-dependent terms like long and short? That's
> >certainly the most glaring deficiency in C with regard to portability.
> 
> That depends on how you look at it. I'd say that it requires a little
> more thought and skill to write portably with types that have sizes
> that are not fully specified, but it's not impossible.
> 
> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
> and LONG_MAX. These tell you what the implementation's least and
> greatest values of type long are. These values are guaranteed to be
> at least -2^31+1 and 2^31-1 respectively.
> 
> If you assume that the long type has a range that is no larger than this,
> you are OK. If you write your code under the assumption that the
> range is LONG_MIN to LONG_MAX, you are also OK.

That's missing the point.  By having application-specific ranges for
integers and accuracy for floating point types, an Ada programmer finds out
*at compile time* that their new target cannot handle the program they are
porting.  Sure, we can all play with assuming what the portable ranges are,
but compile-time checking finds them earlier and thereby cheaper, than
hopefully having users detecting a bug.  In Ada, we know predefined Integer
is at least 16 bits, but best approach is to avoid it when possible, since
the more portable alternative is available.

In all honesty, I think the reason this point is missed by so many is that
some languages cannot express ranges, so the concept of portability is
differing.

Another side of the issue is what can be done with the information that the
compile-time info provides.  For languages like C++ which can at least
check ranges by overloading indexing and checking the range of the
specified parameter, (and throwing an exception if violated), can the
compiler optimize away the check in the static (compile-time-known) cases? 
Languages which know at compile time what the ranges can be and can do the
flow analysis can remove unnecessary checks.  (Ada is such a language.)

Re: Porting Experiences (was Ada and Pascal etc )

[James Youngman]

>>>>> "Shmuel" == Shmuel (Seymour J ) Metz <nospam@gsg.eds.com> writes:

  Shmuel> Lawrence Kirby wrote:
  >> 1. If the range is contained within -32767 to 32767 then you use
  >> int
  >> 
  >> 2. If the range is contained within -2147483647 to 2147483647
  >> then you use long.
  >> 
  >> 3. If you want to minimise space usage (such as for array
  >> elements or structure members) and the range is contained within
  >> -32767 to 32767 then you can use short. For -127 to 127 you can
  >> use signed char.
  >> 
  >> 4. The unsigned types have larger positive ranges if your range
  >> is non-negative. Notably unsigned char typically corresponds to
  >> the notion of "byte" in most languages.

  Shmuel> Those rules only apply if you are going from one 32-bit
  Shmuel> machine to another; they have nothing to do with the
  Shmuel> definition of C itself and are inapplicable when you have to
  Shmuel> move between different word sizes.

No, Lawrence is right; refer to page 257 of Kernighan and Ritchie 2ed
(section B11, "Implementation-defined Limits: <limits.h> and
<float.h>", or section [mumble] of the actual standard document.

Re: Porting Experiences (was Ada and Pascal etc )

[Boyd Roberts]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]


In article <63p0u1$uvm$1@helios.crest.nt.com>, kaz@helios.crest.nt.com (Kaz Kylheku) writes:
>
>Sure there is. Say we are talking about a signed quantity. You first identify
>the range that it shall require. If it is within -127 to 127, you may use a
>char type---IF it is important for you to save storage.  Otherwise you use int.
>If the range is within -32767 to 32767, you use a short if saving storage is
>important. Otherwise you use int.  If the range is outside -32767 to 32767 but
>within -2^32+1 to 2^32-1, you use the type long. Otherwise if you require a
>larger range, you are out of luck. To stay within the limits of strictly
>conforing C, you must emulate some higher precision arithmetic.

Absolutely.  You decide whether the type will be large enough to hold
the values you want to represent and you use it.  You do this rather
than cluttering up the language with a lot of excess baggage that could
be expressed far more simply.

Code all the ADA you like.  Small amount of overflow and there goes an Ariane 5.

-- 
Boyd Roberts <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

Re: Porting Experiences (was Ada and Pascal etc )

[Steve Summit]

[followups trimmed slightly]

In article <345F9728.D61@gsg.eds.com>, nospam@gsg.eds.com writes:
> Lawrence Kirby wrote:
>> As ever the C language is designed
>> with the assumption that the programmer knows what he is doing. The use
>> of ranges implies that you know beforehand what those ranges will be.
>> In C you follow a set of rules:
>> 1. If the range is contained within -32767 to 32767 then you use int
>> 2. If the range is contained within -2147483647 to 2147483647 then you
>>    use long.
>>...
> 
> Those rules only apply if you are going from one 32-bit machine to
> another; they have nothing to do with the definition of C itself and are
> inapplicable when you have to move between different word sizes.

What on earth are you talking about?  The rules Lawrence cited
(including the two I snipped) are taken *directly* from "the
definition of C itself", both the original K&R definition and the
modern ANSI/ISO definition.

> The C standard makes the size of an int implimentation dependent...

Correct.

> and on
> 16-bit machines it is normally 16. On 64-bit machines int is usually 64,
> and if you want 32 you specify short.

And on both of those machines, a program that attempted to store
numbers in the range +-32767 in ints or short ints would work
without change.

If you write C programs that "want" ints of certain sizes, such
as 16 or 32 bits, you will have portability headaches 'til the
end of your days.  If you write programs that assume that types
int and short int have a range of +-32767, and that long int has
a range of +-2147483647, your programs will work under every C
compiler everywhere, including compilers you've never heard of,
or that haven't been written yet, for machines that haven't been
built or even dreamed of yet, including those with 17-bit short
ints and 23-bit ints and 41-bit long ints.  *That's* portability.
Rewriting your program or adjusting all its typedefs every time
you port it to a new machine is an exercise in futility.

					Steve Summit
					scs@eskimo.com

Re: Porting Experiences (was Ada and Pascal etc )

[Samuel T. Harris]

Reading the arguments between Kaz and others, I'm struck
with the realization that Kaz is missing a significant
point. As long as application code is not concerned
with the representation of variables, Kaz is correct
in his statements that a few simple guidelines insure
good type choices for portable C code. What Kaz has
failed to consider, but has been state by others, is
that sometimes the representation of the type IS
important to the application, or at least to the
context in which the application is running.

The classic example here is a 32-bit integer. While
application usually are only concerned witht he RANGE
supported by the type (and Kaz's guidelines do insure
a proper choice of type) the context in which the
app is running may force the use of a 32-bit integer,
especially when interfacing to hardware, COTS libraries,
or in a distributed environment where heterogenous
architectures must interface with each other. These
are common examples of the context forcing a representation.
C does not support forcing the representation in a
portable way. Ada does. The need for such cannot
be simply dismissed because the need is real.

In fact, Ada provides me facilities to exactly map
the representation of a record right down to the
location and size of each field to conform to the
requirements of memory-mapped hardware registers.
This is very powerful and convenient. I can even
use this facility to insure the record structures
across different hardware/compiler combination are
compatible and simply send the records themselves
over the interface with little or no pre/post
processing.

With Ada, I can force a particular variable to
sit upon a particular address without any cumbersome
intermediate pointer. This is how I place my
exactly constructured record variable on top of
the actual memory area where the hardware has
placed its registers.

While it is true that support for these facilities
is optional and can involve implementations specific
limitations, in practise, commercial compilers do
in fact support these facilities to a great degree.
Such concerns simply become requirements as to
compiler selection. All compilers which support these
facilities (which is indeed nearly all compilers
I've used) will represent said structures in exactly
the same manner because the repsentation clauses
leave no room for interpretation. Hence my specific
machine, operating system, nor compiler affects
my portability since my source remains invariant
across all there of these variations.

So, I can't say to Kaz that he is wrong, because
he is not, as far as he goes. What I do say to Kaz
is "You have only pricked the tip of the portability
iceberg." Portability involves much more than guaranteeing
the base range of types. Code with specific ranges
and specific representations (including size and layout)
must also be portable, especially with the rise of
distributed computing and the integration of COTS
products with custom code. C simply does not have the
language features to support any but the most
rudimentary porting requirements of single-machine,
black-box applications that run by themselves or
with others in a strictly homogeneous environment
all of which are built with a strictly compatible
set of tools. Any variation in the above, rather
limiting set of circumstances, forces the C developer
to address many considerations to insure proper
type choice. Issues which simply do not concern me
when I'm using Ada.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Porting Experiences (was Ada and Pascal etc )

[Chris Brand]

Kaz Kylheku wrote:
> 
> In article <345F9728.D61@gsg.eds.com>,
> Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
>  >Lawrence Kirby wrote:
>  >>
[big snip]
>  >>
>  >> 2. If the range is contained within -2147483647 to 2147483647 then you
>  >>    use long.
>  >>
[bigger snip]
> 
> Look, if you find something factually wrong in a Lawrence Kirby posting, I
> shall promptly mail you a lollipop! :)

and in a differnet posting,

Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
>Kaz Kylheku wrote:
>> 
[snip]
>> 
>> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
>> and LONG_MAX. These tell you what the implementation's least and
>> greatest values of type long are. These values are guaranteed to be
>> at least -2^31+1 and 2^31-1 respectively.
>> 
>> If you assume that the long type has a range that is no larger than this,
>> you are OK. If you write your code under the assumption that the
>> range is LONG_MIN to LONG_MAX, you are also OK.
>> 
[another snip]

So, Lawrance Kirby claims that -2147483647 to 2147483647 will fit in a
long, while you claim that you can only rely on -2^31+1 to 2^31-1.

Do I get a lollipop, or are you wrong ?

-- 
Chris
Stating my own opinions, not those of my company.

[Ignore lines down here, they're just to satisfy my newsserver]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

Re: Porting Experiences (was Ada and Pascal etc )

[Lawrence Kirby]

In article <3460CF02.3C99@ccgate.hac.com>
           cbrand@ccgate.hac.com "Chris Brand" writes:

...

>So, Lawrance Kirby claims that -2147483647 to 2147483647 will fit in a
>long, while you claim that you can only rely on -2^31+1 to 2^31-1.
>
>Do I get a lollipop, or are you wrong ?

Assuming you realise that ^ is a common way to represent "raised to the
power of" (not C's exclusive-OR operator here!) and in maths expressions
it tends to get a very high precedence, I'm not quite sure what you believe
the difference to be. (2 raised to the power of 31)-1 is 2147483647.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <3460CF02.3C99@ccgate.hac.com>,
Chris Brand  <cbrand@ccgate.hac.com> wrote:
>So, Lawrance Kirby claims that -2147483647 to 2147483647 will fit in a
>long, while you claim that you can only rely on -2^31+1 to 2^31-1.
>
>Do I get a lollipop, or are you wrong ?

The ^ symbol means exponent rather than exclusive or, and is intended to have a
higher precedence than the unary minus or the addition operator, so
that -2^8 means -(2^8) or -256.

Thus

    -2^31+1  =  -2147483647

and

     2^31-1  =   2147483647

Lawrence and I are claiming the exact same thing stated in different terms.
I'm sometimes too lazy to write the decimal constants.

No lollipop.
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Kaz Kylheku wrote:
 
> >C will remain a serious blot on the claims of portability.
> 
> This simply isn't true. There may be blots on that claim, but this isn't one of
> them. It's an imagined problem that perhaps stems from your inexperience with
> that particular language.

Ah, the old ad hominem argument! I suppose it's all right when you have
no other arguments to bolster your case.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Craig Franck wrote:
> 
> C is no less portable because of this. You may have a case if you
> state that, perhaps, in this particular aspect of constructing
> portable programs, Ada is more efficient. You can define your basic
> types and have the compiler figure it all out. That may make for
> more optimal code generation. But optimal code generation is not
> the main goal of portable software. If the code runs half as fast
> as a native assembler coded routine done by some asm guru whose
> been pounding away at it for a week, you should be happy with your
> tools.

It's not just an efficiency issue. As an example, if I have to process
data from the outside world, there is no portable way to declare them in
C.

As to the comparison with assembler, there are two problems with it.
First, the alternative under discussion was Ada, and that's more
maintainable than C, not less. Second, if you are using a modern
assembler with a decent macro processor, the assembler code is likely to
be more maintainable than C code as well (yes, I know that it won't be
as tight as hand coded one-for-one, but that doesn't bother me.)

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>Craig Franck wrote:
> 
>> That was mentioned in an several e-mails I received. 
>
>Since I last posted I saw an article stating that the next C standard
>will include a way to specify the required precision. That will be a
>welcome change!
>
>> It seems you can define the interface with the machine in Ada; in
>> C, what you would do is keep the values in the portable range as
>> defined by the standard. This isn't as bad as it would seeem. If
>> an implementation decides 64-bit ints are the best representation,
>> a short, int, and long could all be 64-bits. Portable software just
>> wouldn't exceed 32,767 for an int.
>
>Which is the same situation that we had when C first emrged, except that
>8-bit processors are no longer an issue. If I need more than 32 bits,
>how fo I declare it without getting 128 bits on some machines? 

There are ways to tune code for a particular platform in C and 
have it still remain portable. 

The case of an int being 32-bits and a long 64 (on a particular 
platform), and you want something larger than UINT_MAX, boy, 
isn't it a waste to declare it as a long, is that what you are 
getting at?

I don't see it as a major issue.

>With Ada
>or PL/I the issue doesn't arise.

I imagine it arises with the compiler people! :-)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>Kaz Kylheku wrote:
>> 
>> That depends on how you look at it. I'd say that it requires a little
>> more thought and skill to write portably with types that have sizes
>> that are not fully specified, but it's not impossible.
>> 
>> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
>> and LONG_MAX. These tell you what the implementation's least and
>> greatest values of type long are. These values are guaranteed to be
>> at least -2^31+1 and 2^31-1 respectively.
>> 
>> If you assume that the long type has a range that is no larger than this,
>> you are OK. If you write your code under the assumption that the
>> range is LONG_MIN to LONG_MAX, you are also OK.

>Unless and until the new standard passes, this aspect of
>C will remain a serious blot on the claims of portability.

C is no less portable because of this. You may have a case if you
state that, perhaps, in this particular aspect of constructing
portable programs, Ada is more efficient. You can define your basic
types and have the compiler figure it all out. That may make for
more optimal code generation. But optimal code generation is not
the main goal of portable software. If the code runs half as fast
as a native assembler coded routine done by some asm guru whose
been pounding away at it for a week, you should be happy with your 
tools.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Lawrence Kirby]

In article <345F9728.D61@gsg.eds.com> nospam@gsg.eds.com "Seymour J." writes:

>Lawrence Kirby wrote:
>> 
>> The portability implications of this are small or non-existent (there may
>> be performace implications in rare circumstances, and issues relating to
>> data sizes and external data formats). As ever the C language is designed
>> with the assumption that the programmer knows what he is doing. The use
>> of ranges implies that you know beforehand what those ranges will be.
>> In C you follow a set of rules:
>> 
>> 1. If the range is contained within -32767 to 32767 then you use int
>> 
>> 2. If the range is contained within -2147483647 to 2147483647 then you
>>    use long.
>> 
>> 3. If you want to minimise space usage (such as for array elements or
>>    structure members) and the range is contained within -32767 to 32767 then
>>    you can use short. For -127 to 127 you can use signed char.
>> 
>> 4. The unsigned types have larger positive ranges if your range is
>>    non-negative. Notably unsigned char typically corresponds to the
>>    notion of "byte" in most languages.
>
>Those rules only apply if you are going from one 32-bit machine to
>another; they have nothing to do with the definition of C itself and are
>inapplicable when you have to move between different word sizes.

Please take a look at the ISO C standard before making bold statements
such as this. These limits are laid in stone within the standard, for your
reference in section 5.2.4.2.1. Code following these guidelines is guaranteed
to work on *any* conforming C compiler with *any* word size. You don't
get more portable that that within the boundaries of a single language.

>The C standard makes the size of an int implimentation dependent,

Yes, it is implementatio-defined but with firm minimum limits, exactly
as stated above.

>and on
>16-bit machines it is normally 16.

True.

>On 64-bit machines int is usually 64,
>and if you want 32 you specify short.

That's an unwarranted assumption which will cause code to be non-portable
so if you want to write portable code you don't make it.

>Now, admittedly this will change with the new standard, but as long as
>it is still a draft it has nothing to do with the current language.

You need to take a look at what the standard for the current language
actually says.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Dann Corbit]

Chris Brand wrote in message <3460CF02.3C99@ccgate.hac.com>...
[snip]
>So, Lawrance Kirby claims that -2147483647 to 2147483647 will fit in a
>long, while you claim that you can only rely on -2^31+1 to 2^31-1.
2^31 =  2147483648
-2^31+1 = -2147483647
2^31 - 1 =  2147483647

You get a question mark
?

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <3460A7BB.3CCD27DC@hso.link.com>,
Samuel T. Harris <s_harris@hso.link.com> wrote:
>Reading the arguments between Kaz and others, I'm struck
>with the realization that Kaz is missing a significant
>point. As long as application code is not concerned
>with the representation of variables, Kaz is correct
>in his statements that a few simple guidelines insure
>good type choices for portable C code. What Kaz has
>failed to consider, but has been state by others, is
>that sometimes the representation of the type IS
>important to the application, or at least to the
>context in which the application is running.

Then the application is not portable, by definition.  A portable program is one
which is not concerned with the representation of a type.

>The classic example here is a 32-bit integer. While
>application usually are only concerned witht he RANGE
>supported by the type (and Kaz's guidelines do insure
>a proper choice of type) the context in which the

Those are not only my guidelines, but have been reiterated by other comp.lang.c
regulars. They are also reflected in the comp.lang.c FAQ.

>app is running may force the use of a 32-bit integer,
>especially when interfacing to hardware, COTS libraries,

Interfacing to hardware is outside of the domain of a strictly conforming
C program.  A pure C language program communicates with the environment
only through streams.

There are ways, using C, to conform to external storage layouts in maximally
portable ways which do not depend on the representation of types other
than the type unsigned char.

>or in a distributed environment where heterogenous
>architectures must interface with each other. These

I have programmed in such circumstances and managed to remain strictly
conforming. Interfacing heterogeneous architectures can be solved by
identifying a canonical external representation format and then writing
maximally portable routines which encode data items to and from that
format. In my experience, only floating point representations represent
any significant difficulties in this area. 

>are common examples of the context forcing a representation.
>C does not support forcing the representation in a
>portable way. Ada does. The need for such cannot
>be simply dismissed because the need is real.

But C allows you to manipulate individual bytes, and therein lies the
secret.

>In fact, Ada provides me facilities to exactly map
>the representation of a record right down to the
>location and size of each field to conform to the
>requirements of memory-mapped hardware registers.

This is also possible with C in a portable way. It is not that convenient, of
course, but we are discussing portability, rather than convenience.

>This is very powerful and convenient. I can even

I couldn't agree more, but please stick to the topic which is portability.

>So, I can't say to Kaz that he is wrong, because
>he is not, as far as he goes. What I do say to Kaz
>is "You have only pricked the tip of the portability
>iceberg." Portability involves much more than guaranteeing

That's because I was only asked to scratch the surface, because
the subject that arose was the choice of integral types to suit
particular requirements. Now we are on the topic of conforming
to external storage formats, which is something else. You haven't
requested a discussion of this topic before.

Conforming to external data layout can be done in a highly portable way in C.
It can also be done in non-portable ways which are usually faster.  

Instead of useless talk, why don't we try the following game: you describe the
storage layout, and I will demonstrate a maximally portable C example which can
communicate with that layout. I will entertain you as long as you wish.

Perhaps you will emerge out of this better armed for situations in which
you have to use C rather than some other preferred tool such as Ada.

>products with custom code. C simply does not have the
>language features to support any but the most
>rudimentary porting requirements of single-machine,
>black-box applications that run by themselves or
>with others in a strictly homogeneous environment
>all of which are built with a strictly compatible
>set of tools.

That depends on what you mean by language features. If you mean that C
doesn't have language features that are *specifically* designed to help you in
this area, then you are right.
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <3460CF02.3C99@ccgate.hac.com>,
Chris Brand  <cbrand@ccgate.hac.com> wrote:

>Do I get a lollipop, or are you wrong ?

Incidentally, I only offered the lollipop to one named Shmuel Metz, so you can
find all the Kirby errors you want, but you ain't getting no candy from me.
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>Lawrence Kirby wrote:
>> 
>> The portability implications of this are small or non-existent (there may
>> be performace implications in rare circumstances, and issues relating to
>> data sizes and external data formats). As ever the C language is designed
>> with the assumption that the programmer knows what he is doing. The use
>> of ranges implies that you know beforehand what those ranges will be.
>> In C you follow a set of rules:
>> 
>> 1. If the range is contained within -32767 to 32767 then you use int
>> 
>> 2. If the range is contained within -2147483647 to 2147483647 then you
>>    use long.
>> 
>> 3. If you want to minimise space usage (such as for array elements or
>>    structure members) and the range is contained within -32767 to 32767 then
>>    you can use short. For -127 to 127 you can use signed char.
>> 
>> 4. The unsigned types have larger positive ranges if your range is
>>    non-negative. Notably unsigned char typically corresponds to the
>>    notion of "byte" in most languages.
>
>Those rules only apply if you are going from one 32-bit machine to
>another; they have nothing to do with the definition of C itself and are
>inapplicable when you have to move between different word sizes.

Huh? Those limits are contained in the standard. 

       5.2.4.2 Numerical limits. 
       ...
       5.2.4.2.1 Sizes of integral types <limits.h>
       ...
       Their implementation-defined values shall be equal or greater 
       in magnitude (absolute value) to those shown, with the same 
       sign.
       ...
       -- minimum value for an object of type int
       INT_MIN                                  -32767

       -- maximum value for an object of type int
       INT_MAX                                  +32767

>The C standard makes the size of an int implimentation dependent, and on
>16-bit machines it is normally 16. On 64-bit machines int is usually 64,
>and if you want 32 you specify short.

Yes, but portable ranges are defined by the standard, and that's 
what you should go by.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Marin David Condic, 561.796.8997, M/S 731-96]

Lawrence Kirby <fred@GENESIS.DEMON.CO.UK> writes:
>The portability implications of this are small or non-existent (there may
>be performace implications in rare circumstances, and issues relating to
>data sizes and external data formats). As ever the C language is designed
>with the assumption that the programmer knows what he is doing. The use
>of ranges implies that you know beforehand what those ranges will be.
>In C you follow a set of rules:
>
    I think you missed a very important point and one that has trashed
    many attempted ports in my experience.

    While the rules you cite do guarantee a minimum accuracy and
    intelligent use thereof certainly does help things, what do you do
    about all the representation issues? Technically, that integer you
    specify as needing a minimum of 16 bits could get represented with
    32 bits. Suppose that it is used in an I/O record to a data file?
    Now you're incompatible with all the data files built by another
    version which allocated only 16 bits. Or suppose it is passed as a
    parameter to an OS routine or routine written in another language
    or a routine written in C but compiled with a different compiler?

    There are *many* occasions where the internal representation of a
    data item is *critical* to the success of a system. Hence not
    having the ability to explicitly state what sort of representation
    is required can hurt portability. I don't see why C can't be
    modified in some subsequent standard to let the programmer dictate
    that a given number be represented a certain way, so I don't think
    it is the end of the world. But as things stand now, this is a
    weakness in the language that hurts portability and if something
    *does* successfully port without changes, it happens more by
    accident than by design.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
===============================================================================
    "Some people say a front-engine car handles best. Some people say
    a rear-engine car handles best. I say a rented car handles best."
        --  P. J. O'Rourke
===============================================================================

Re: Porting Experiences (was Ada and Pascal etc )

[Alan E & Carmel J Brain]

Kaz Kylheku wrote:
> 
> In article <3460A7BB.3CCD27DC@hso.link.com>,
> Samuel T. Harris <s_harris@hso.link.com> wrote:
> >Reading the arguments between Kaz and others, I'm struck
> >with the realization that Kaz is missing a significant
> >point. As long as application code is not concerned
> >with the representation of variables, Kaz is correct
> >in his statements that a few simple guidelines insure
> >good type choices for portable C code. What Kaz has
> >failed to consider, but has been state by others, is
> >that sometimes the representation of the type IS
> >important to the application, or at least to the
> >context in which the application is running.
> 
> Then the application is not portable, by definition.  A portable program is one
> which is not concerned with the representation of a type.

I most strongly disagree. A very, very typical counterexample, found in
many, many systems is an I/O handler. For this, there is a standard
protocol
defined at some level, stating the bit representation of the telegrams.

Consider a telegram containing (in a representation-free sense):
A telegram type, which is between 0 and 255;
A value, which is between 0 and 20000
A 10-character string
6 status flags

This is implemented in the specification of the interface as:
Bytes 0     Telegram type
Bytes 1     Bytes of which the 6 MSBs are the status flags
Bytes 2-4   unused
Bytes 5-7   The value up to 20000
Bytes 8-17  The character string in ANSI 8-bit, no terminator
Bytes 18-19 Unused

All boxes on the bus must have a piece of code that can "decode" this
telegram. In C, using different C compilers, sure you need #ifdefs and
all sorts of other things. In Ada, even Ada-83, the same code on
different
CPUs with different compilers is guarenteed to use the same
representation,
if you use the representation clauses provided with the language.

For example:
type TelegramKindType is ( Conflict, Priority);
for TelegramKindType use ( Conflict => 16#FF, Priority => 2#10101010);
for TelegramKindType'size use 8; -- 8 bits exactly, no more, no less
 
type TelegramType is
record
  TheKind : TelgramKindType;
etc etc etc

and

for TelegramType use
record at mod 8        -- align it to some very portable word boundary
  TheKind at 0 range 0..7;
etc etc etc

The point is that the _exact same_ chunk of code is used in _every_
machine.
Now if that's not portable, what is?

> Interfacing to hardware is outside of the domain of a strictly conforming
> C program.  A pure C language program communicates with the environment
> only through streams.

Sounds as if Ada's more powerful here -->  :) <----

> I have programmed in such circumstances and managed to remain strictly
> conforming. Interfacing heterogeneous architectures can be solved by
> identifying a canonical external representation format and then writing
> maximally portable routines which encode data items to and from that
> format. In my experience, only floating point representations represent
> any significant difficulties in this area.

I agree, obviously you'll recognise the Ada example I gave above. In
Ada,
the problem's actually worse: in most cases, the language allows
complete
portability, you get used to it. But then along comes a problem where
the
communications telegram has IEEE floats, and the machine you're on only
has
DEC (or other) floats. In which case you have to write some more code.

BTW this is an actual example, I headed the team doing the I/O over a
VME
bus (Many MB/sec) between a KAV (DEC) card and an i860 card. Under
pressure
from management (execution time was crucial) an assembler Float
converter was written
by an Assembler guru. After 2 weeks, a C program was written, that was
actually faster, and worked (unlike the assembler).

Of course later, I then wrote an Ada conversion routine, that due to an
excellent
compiler, was faster still, but that's another matter.

> >In fact, Ada provides me facilities to exactly map
> >the representation of a record right down to the
> >location and size of each field to conform to the
> >requirements of memory-mapped hardware registers.
> 
> This is also possible with C in a portable way. It is not that convenient, of
> course, but we are discussing portability, rather than convenience.

> Conforming to external data layout can be done in a highly portable way in C.
> It can also be done in non-portable ways which are usually faster.
> 
> Instead of useless talk, why don't we try the following game: you describe the
> storage layout, and I will demonstrate a maximally portable C example which can
> communicate with that layout. I will entertain you as long as you wish.
> 
> Perhaps you will emerge out of this better armed for situations in which
> you have to use C rather than some other preferred tool such as Ada.

YES PLEASE. Any help from anyone is always welcome. So much to learn,
and only one lifetime, *SIGH*

OK, I would like the following:

1st(0th) byte contains telegram type. This has legal values of FF,FE,and
00.
If the value is FF, then bytes 4-7 contain an IEEE floating point
between
-1.7666 e6 and 2.34 e12. Byte 3 contains an enumeration type, which has
the values Red,Green, Yellow, corresponding to 01, 10, and FF (hex).
If the value is FE, bytes 1-3 contain a binary angle (fixed point),
first 13
bits before the binary point. Bytes 4-11 contain a packed ANSI 7-bit
string.
If the value is 00, then the rest is "don't care".

The reading in must check that all values are correct. The floating
point
will be decoded into the form of mantissa, sign, exponent etc.

This is a nice, simple one. I'll get into the really polymorphic records
later.

Over 2 U.
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Porting Experiences (was Ada and Pascal etc )

[Paul Campbell]

Alan E & Carmel J Brain wrote:

> 
> This is implemented in the specification of the interface as:
> Bytes 0     Telegram type
> Bytes 1     Bytes of which the 6 MSBs are the status flags
> Bytes 2-4   unused
> Bytes 5-7   The value up to 20000

Byte ordering for integral types varies across machines so
you must have stuck lucy for this to have worked.

Paul C.
UK.

Re: Porting Experiences (was Ada and Pascal etc )

[Lawrence Kirby]

In article <34610614.33AC@gsg.eds.com> nospam@gsg.eds.com "Seymour J." writes:

>Craig Franck wrote:
>> 
>> C is no less portable because of this. You may have a case if you
>> state that, perhaps, in this particular aspect of constructing
>> portable programs, Ada is more efficient. You can define your basic
>> types and have the compiler figure it all out. That may make for
>> more optimal code generation. But optimal code generation is not
>> the main goal of portable software. If the code runs half as fast
>> as a native assembler coded routine done by some asm guru whose
>> been pounding away at it for a week, you should be happy with your
>> tools.
>
>It's not just an efficiency issue. As an example, if I have to process
>data from the outside world, there is no portable way to declare them in
>C.

Certainly there is, you may have to do slightly more work explicitly. In
C you can treat any byte format as a sequence of unsigned chars. There's
plenty of portable C code around to deal with, for example, stadnard file
formats such as GIF and ZIP.

>As to the comparison with assembler, there are two problems with it.
>First, the alternative under discussion was Ada, and that's more
>maintainable than C, not less.

I won't argue eihter way there. You may be right to some degree, but the
point is that C isn't as unmaintainable as you seem to make out.

>Second, if you are using a modern
>assembler with a decent macro processor, the assembler code is likely to
>be more maintainable than C code as well (yes, I know that it won't be
>as tight as hand coded one-for-one, but that doesn't bother me.)

However that is an absurd statement. There has beena large trend of moving
from assembly to C (embdeed systems development is a good example) precisely
because the latter is more maintainable. Macros help but they aren't a
universal panacea. If macros are so good how often do you use them in Ada?

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <34623DA4.7EE5@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@dynamite.com.au> wrote:
>YES PLEASE. Any help from anyone is always welcome. So much to learn,
>and only one lifetime, *SIGH*
>
>OK, I would like the following:
>
>1st(0th) byte contains telegram type. This has legal values of FF,FE,and 00.
>If the value is FF, then bytes 4-7 contain an IEEE floating point between
>-1.7666 e6 and 2.34 e12. Byte 3 contains an enumeration type, which has the
>values Red,Green, Yellow, corresponding to 01, 10, and FF (hex).  If the value
>is FE, bytes 1-3 contain a binary angle (fixed point), first 13 bits before
>the binary point. Bytes 4-11 contain a packed ANSI 7-bit string.  If the value
>is 00, then the rest is "don't care".
>
>The reading in must check that all values are correct. The floating point will
>be decoded into the form of mantissa, sign, exponent etc.
>
>This is a nice, simple one. I'll get into the really polymorphic records
>later.
>
>Over 2 U.

Okay, first of all we make the assumption that the octets in this datagram are
mapped to bytes in the C execution environment, which need not be octets.  This
is an issue which has to do with how the data are communicated to the execution
environment of the C program. For example, on an IBM mainframe that has 9 bit
bytes, data brought in from the 8 bit world are not chopped into 9 bit units,
but rather their octets are mapped to individual 9 bit bytes which then
have the values 0 to 255 (if interpreted as unsigned char).

The IEEE floating point handling is probably going to be a little shaky, but I
will do my best.

I haven't fully tested this (due to boredom), so let me know if I missed a
requirement, or botched something up.

I also have only implemented the decoding of the telegram, not encoding.

/*------------------------------------------------------------------------*/

    #include <stddef.h>	/* for size_t	*/
    #include <math.h>	/* for ldexp()	*/

    /* 
     * First, we declare some C data type that _internally_ represents the
     * telegram/datagram.
     */

    typedef enum { red = 0x01, green = 0x10, yellow = 0xff } telegram_color;

    typedef struct {
	int type;
	double number;
	unsigned long angle;
	telegram_color color;
	char string[10];
    } telegram;

    int telegram_decode(telegram *tel, unsigned char *buf);
    double ieee_single_decode(unsigned char *buf);
    unsigned long fixed_24_decode(unsigned char *buf);
    void packed_string_decode(unsigned char *dest, unsigned char *src, size_t);

    /*
     * Then we write a routine which decodes that packet from a buffer of
     * bytes, which we assume contains a complete telegram.  We return 0 if
     * there is something wrong with the telegram's contents, 1 if the decoding
     * is successful.  We assume that the buffer has been prepared such that
     * all bytes are in the range 0 to 255 even if unsigned char has a larger
     * range.
     */

    int telegram_decode(telegram *tel, unsigned char *buf)
    {
	switch (tel->type = buf[0]) {
	case 0xFF:	/* legal values */
	    tel->number = ieee_single_decode(buf + 4);
	    if (tel->number < -1.7666E6 || tel->number > 2.34E12)
		return 0;
	    tel->color = buf[3];
	    if (tel->color!=red && tel->color!=green && tel->color!=yellow)
		return 0;
	    break;
	case 0xFE:
	    tel->angle = fixed_24_decode(buf + 1);
	    packed_string_decode(tel->string, buf + 4, 8);
	    tel->string[9] = 0;
	    break;
	case 0x00:
	    break;
	default:	/* or exit */
	    return 0;
	}

	return 1;
    }
  
    /*
     * decode an IEEE single precision number, assumed to be stored
     * in big endian, broken into individual octets.
     * An IEEE 754 single precision number consists of a sign bit,
     * eight bits of binary exponent biased by adding 127, and
     * 23 bits of mantissa with an implicit 1 stripped away.
     * We try to convert this to a value of type double.
     */

    double ieee_single_decode(unsigned char *buf)
    {
	int sign, exponent;
	unsigned long mantissa;
	double mantdouble, result;


	/*
	 * extract the sign bit as an int valued 1 or 0
	 * representing negative and positive, respectively.
	 */

	sign = ((buf[0] & 0x80) != 0);

	/*
	 * extract the exponent as a negative integer
	 */

	exponent = ((buf[0] & 0x7f) << 1 | (buf[1] >> 7)) - 127;

	/*
	 * extract the mantissa as a 24 bit integer, with the implicit
	 * 1 put back in explicitly
	 */

	mantissa = (1UL << 23) | (unsigned long) (buf[1] & 0x7f) << 16;
	mantissa |= (unsigned) (buf[2] << 8) | buf[3];

	/*
	 * compute the mantissa as a floating point number in the
	 * range [0,1)
	 */

	mantdouble = (double) mantissa / (1UL << 23);


	/*
	 * compute mantdouble * 2**exponent using the standard function.
	 */

	result = ldexp(mantdouble, exponent);

	/*
	 * factor in the sign and return the result
	 */

	return (sign) ? -result : result;
    }

    /*
     * extract a 24 bit fixed point number from three
     * octets. For now, this is just represented as a
     * scaled, unsigned integer, so this operation
     * is trivial.
     */

    unsigned long fixed_24_decode(unsigned char *buf)
    {
	return (unsigned long) buf[0] << 16 | (unsigned) buf[1] << 8 | buf[2];
    }

    /*
     * Decode a 7 bit string packet into eight bits
     * We basically loop over groups of 7 bytes (or 56 bits)
     * since 56 is the least common multiple of 8 and 7.
     * Then handle the remainder of the data which may be
     * less than a full 56 bit block.
     *
     * Parameter n is the number of octets of the input packet,
     * NOT the number of 7 bit characters to be extracted.
     *
     * There are more efficient ways to code this to defeat
     * assumptions of aliasing that the compiler has to make.
     */

    void packed_string_decode(unsigned char *dest, unsigned char *src, size_t n)
    {
	while (n >= 7) {
	    dest[0] =                        src[0] >> 1;
	    dest[1] = (src[0] & 0x01) << 6 | src[1] >> 2;
	    dest[2] = (src[1] & 0x03) << 5 | src[2] >> 3;
	    dest[3] = (src[2] & 0x07) << 4 | src[3] >> 4;
	    dest[4] = (src[3] & 0x0f) << 3 | src[4] >> 5;
	    dest[5] = (src[4] & 0x1f) << 2 | src[5] >> 6;
	    dest[6] = (src[5] & 0x3f) << 1 | src[6] >> 7;
	    dest[7] =  src[6] & 0x7f;

	    dest += 8;
	    src += 7;
	    n -= 7;
	}

	/* note the reversal of the order of the above dest[] assignments in
	   the cases below */

	switch (n) {
	case 6:
	    dest[5] = (src[4] & 0x1f) << 2 | src[5] >> 6;
	case 5:
	    dest[4] = (src[3] & 0x0f) << 3 | src[4] >> 5;
	case 4:
	    dest[3] = (src[2] & 0x07) << 4 | src[3] >> 4;
	case 3:
	    dest[2] = (src[1] & 0x03) << 5 | src[2] >> 3;
	case 2:
	    dest[1] = (src[0] & 0x01) << 6 | src[1] >> 2;
	case 1:
	    dest[0] =  src[0] >> 1;
	case 0:
	    break;
	}
    }


/*------------------------------------------------------------------------*/

Here is an example of a packed six-bit data encoding routine which has been
aggressively coded to save the compiler from making pessimistic aliasing
assumptions. Here, the variables x and y are used as temporary values
which eliminate redundant loads from the source array, so that the bare minimum
number of pointer dereference operations is performed. In principle,
the same sort of technique can be applied to packed_string_decode().

    size_t sixbit_encode(unsigned char *dest, unsigned char *src, size_t size)
    {
	size_t out = 0;
	unsigned x, y;

	while (size > 2) {
	    *dest++  = (x = *src++)  >> 2;
	    *dest++  = (x & 3)       << 4  | (y = *src++) >> 4;
	    *dest++  = (y & 15)      << 2  | (x = *src++) >> 6;
	    *dest++  =  x & 63;

	    size -= 3;
	    out += 4;
	}

	switch (size) {
	case 2:
	    *dest++  = (x = *src++)  >> 2;
	    *dest++  = (x & 3)       << 4  | (y = *src) >> 4;
	    *dest++  = (y & 15)      << 2;
	    return out + 3;
	case 1:
	    *dest++  = (x = *src++)  >> 2;
	    *dest++  = (x & 3)       << 4;
	    out += 2;
	default:
	    return out;
	}
    }

Oh, and to dispel any myth that assembly language is easier to maintain than C,
here is a hand-coded 80x86 equivalent:


		.file	"sixbit-i386.s"

ALIGN		= 16

arg1		= 4
arg2		= 8
arg3		= 12

		.text

rcsid:		.ascii	"$Id: sixbit-i386.s,v 1.1 1997/07/26 18:35:35 kaz Exp $"

# 
#  ... snip ...
#

		.globl	sixbit_encode
sixbit_encode:
		pushl	%edi
		pushl	%esi
		pushl 	%ebx
		movl	arg1+12(%esp), %edi
		movl	arg2+12(%esp), %esi
		movl	arg3+12(%esp), %ecx
		xorl	%edx, %edx
		cld

		cmpl	$2, %ecx
		je	encode_two
		jb	encode_one

		.align	ALIGN

encode_threes:
		lodsw	(%esi), %ax
		movb	%al, %bh
		andb	$3, %bh
		shrb	$2, %al
		shlb	$4, %bh
		movb	%ah, %bl
		shrb	$4, %ah
		orb	%bh, %ah
		shll	$16, %eax
		andb	$15, %bl
		lodsb	(%esi), %al
		shlb	$2, %bl	
		movb	%al, %bh
		shrb	$6, %al	
		orb	%bl, %al
		movb	%bh, %ah
		andb	$63, %ah
		roll	$16, %eax
		stosl	%eax, (%edi)

		addl	$4, %edx
		subl	$3, %ecx
		cmp	$2, %ecx
		ja	encode_threes
		jb	encode_one

encode_two:	
		lodsw	(%esi), %ax
		movb	%al, %bh
		shrb	$2, %al	
		andb	$3, %bh	
		shlb	$4, %bh

		movb	%ah, %bl
		shrb	$4, %ah	
		orb	%bh, %ah
		stosw	%ax, (%edi)

		andb	$15, %bl
		shlb	$2, %bl	
		movb	%bl, (%edi)

		addl	$3, %edx
		movl	%edx, %eax

		popl	%ebx
		popl	%esi
		popl	%edi
		ret

encode_one:	
		testl	%ecx, %ecx
		je	encode_done

		lodsb	(%esi), %al
		movb	%al, %ah
		shrb	$2, %al	
		andb	$3, %ah
		shlb	$4, %ah	
		movw	%ax, (%edi)

		addl	$2, %edx

encode_done:
		movl	%edx, %eax
		popl	%ebx
		popl	%esi
		popl	%edi
		ret

-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>Craig Franck wrote:
>> 
>> C is no less portable because of this. You may have a case if you
>> state that, perhaps, in this particular aspect of constructing
>> portable programs, Ada is more efficient. You can define your basic
>> types and have the compiler figure it all out. That may make for
>> more optimal code generation. But optimal code generation is not
>> the main goal of portable software. If the code runs half as fast
>> as a native assembler coded routine done by some asm guru whose
>> been pounding away at it for a week, you should be happy with your
>> tools.
>
>It's not just an efficiency issue. As an example, if I have to process
>data from the outside world, there is no portable way to declare them in
>C.

Sure there is; C programmers do it all the time.

>As to the comparison with assembler, there are two problems with it.
>First, the alternative under discussion was Ada, and that's more
>maintainable than C, not less. 

I think well written code in C or Ada is just about equally maintain-
able by competent programmers in their respective languages.

>Second, if you are using a modern
>assembler with a decent macro processor, the assembler code is likely to
>be more maintainable than C code as well 

That's silly. (You been hanging out with SN?)

>(yes, I know that it won't be
>as tight as hand coded one-for-one, but that doesn't bother me.)

By the time you have a macro assembler as maintainable as C, you 
would have implemented a compiler. At which point using it would
be silly, because C is more portable.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Boyd Roberts]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]


>In article <34610614.33AC@gsg.eds.com> nospam@gsg.eds.com "Seymour J." writes:
>Second, if you are using a modern
>assembler with a decent macro processor, the assembler code is likely to
>be more maintainable than C code as well (yes, I know that it won't be
>as tight as hand coded one-for-one, but that doesn't bother me.)

Third, if you are using a plugboard with a decent diagram the wiring
is likely be more maintainable than assembler as well (yes, I know that
it won't be a total rats-nest as hand plugged one-for-one, but that
doesn't bother me).

-- 
Boyd Roberts <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

Re: Porting Experiences (was Ada and Pascal etc )

[Boyd Roberts]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]


In article <63p2g1$vnt$1@helios.crest.nt.com>, kaz@helios.crest.nt.com (Kaz Kylheku) writes:
>No C programmer who has a clue about portable coding would specify short
>to get a 32 bit type---unless he was worried about using the smallest possible
>type which fits, thus minimizing resource usage!
>

Well they would if they were coding for the Ariane 5.

-- 
Boyd Roberts <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Craig Franck wrote:
> 
> "Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
> >Craig Franck wrote:
> 
> >Second, if you are using a modern
> >assembler with a decent macro processor, the assembler code is likely to
> >be more maintainable than C code as well
> 
> That's silly. (You been hanging out with SN?)

It's not silly, it's true. "Saying "that's silly" instead of presenting
your ervidence, if any, is what's silly.  And I have no idea who SN is.

> >(yes, I know that it won't be
> >as tight as hand coded one-for-one, but that doesn't bother me.)
> 
> By the time you have a macro assembler as maintainable as C, you
> would have implemented a compiler. At which point using it would
> be silly, because C is more portable.

Trying to pur words in my mouth is what's silly here; I never claimed
that the assembler code was portable, just more maintainable. 

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Boyd Roberts wrote:
> 
> >In article <34610614.33AC@gsg.eds.com> nospam@gsg.eds.com "Seymour J." writes:
> >Second, if you are using a modern
> >assembler with a decent macro processor, the assembler code is likely to
> >be more maintainable than C code as well (yes, I know that it won't be
> >as tight as hand coded one-for-one, but that doesn't bother me.)
> 
> Third, if you are using a plugboard with a decent diagram the wiring
> is likely be more maintainable than assembler as well (yes, I know that
> it won't be a total rats-nest as hand plugged one-for-one, but that
> doesn't bother me).

ROTF,LMAO!

Have you evere wired a plug board? Have you written any macros using a
powerfull macro assembler? I go back to the plugboard days, and even
with good documentation (which means a *lot* more than a diagram)
they're not easy to change. Even one-for-one assembler code is more
maintainable than a plug board.

As to rats'-nests, the worst rats' nests that I've seen have been BAIC
and C programs.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Samuel T. Harris]

Before I begin a point-to-point response, I must say
it is refreshing to read a response devoid of ego. I applaud
you and others who are glad to entertain considered discussions
filled with details and facts on the comparative merits.
I also salute your willingness to provide complete C code
supporting your position.

Kaz Kylheku wrote:
> 
> In article <3460A7BB.3CCD27DC@hso.link.com>,
> Samuel T. Harris <s_harris@hso.link.com> wrote:
> >Reading the arguments between Kaz and others, I'm struck
> >with the realization that Kaz is missing a significant
> >point. As long as application code is not concerned
> >with the representation of variables, Kaz is correct
> >in his statements that a few simple guidelines insure
> >good type choices for portable C code. What Kaz has
> >failed to consider, but has been state by others, is
> >that sometimes the representation of the type IS
> >important to the application, or at least to the
> >context in which the application is running.
> 
> Then the application is not portable, by definition.  A portable program is one
> which is not concerned with the representation of a type.

I don't agree. Portability is the ability to compile an run the
same source in several environments. Type representation is not
a application attribute which determines portability.

IMHO a portable program is one which has to run or has potential
to run on heterogenous platforms. By platform I mean the combination
of hardware, operating system, and compiler. Restrictions on
type selection are usually imposed on the context and many times
that context requires the program to satisfy those restrictions
in a portable way because the context spans many platforms.
In such contexts, applications do need to be concerned with
the representation of type AND still be portable. In such
domains, language choice for the project must recognize the
merits of candidate languages and their facilties which support
satisfying these needs. I recognize that the need for distributed
computing involving heterogenous platforms is on the rise. This
means that application domains which did not care about
type representation are now having to consider such issues given
the need/want to run such almost anywhere.

> 
> >The classic example here is a 32-bit integer. While
> >application usually are only concerned witht he RANGE
> >supported by the type (and Kaz's guidelines do insure
> >a proper choice of type) the context in which the
> 
> Those are not only my guidelines, but have been reiterated by other comp.lang.c
> regulars. They are also reflected in the comp.lang.c FAQ.

As you say. A good thing recognized by the C establishment as a good
thing.

> 
> >app is running may force the use of a 32-bit integer,
> >especially when interfacing to hardware, COTS libraries,
> 
> Interfacing to hardware is outside of the domain of a strictly conforming
> C program.  A pure C language program communicates with the environment
> only through streams.
> 

This handicaps C for use in embedded systems.

> There are ways, using C, to conform to external storage layouts in maximally
> portable ways which do not depend on the representation of types other
> than the type unsigned char.

Which, as you detail below, involve conversion routines since the
native C types cannot be used on the storage layouts. While this
is a solution, it does have an execution cost (calling the conversion
routines). This is not to say that Ada is maximally efficient
when using representation clauses. There are times when a specified
record layout causes the compiler to emit inefficient code simply
because the required layout is not "natural" to the platform. Such
situations usually are the result of doing simulation work on
hardware other than the intended target. More on that later.

> 
> >or in a distributed environment where heterogenous
> >architectures must interface with each other. These
> 
> I have programmed in such circumstances and managed to remain strictly
> conforming. Interfacing heterogeneous architectures can be solved by
> identifying a canonical external representation format and then writing
> maximally portable routines which encode data items to and from that
> format. In my experience, only floating point representations represent
> any significant difficulties in this area.

That summarizes my experiences as well. Its just that with Ada, I can
dispense with the conversion/encoding routines when the format lends
itself to direct manipulation. I can't do that with C.

> 
> >are common examples of the context forcing a representation.
> >C does not support forcing the representation in a
> >portable way. Ada does. The need for such cannot
> >be simply dismissed because the need is real.
> 
> But C allows you to manipulate individual bytes, and therein lies the
> secret.

I can manipulate individual bytes with Ada, but I don't have to
in order to achieve portable code in a context requiring specific type
representations, so I don't.

> 
> >In fact, Ada provides me facilities to exactly map
> >the representation of a record right down to the
> >location and size of each field to conform to the
> >requirements of memory-mapped hardware registers.
> 
> This is also possible with C in a portable way. It is not that convenient, of
> course, but we are discussing portability, rather than convenience.
> 
> >This is very powerful and convenient. I can even
> 
> I couldn't agree more, but please stick to the topic which is portability.

This whole thread is about compiling and running the same source
on heterogenous environments. This is on topic and has been
all along.

> 
> >So, I can't say to Kaz that he is wrong, because
> >he is not, as far as he goes. What I do say to Kaz
> >is "You have only pricked the tip of the portability
> >iceberg." Portability involves much more than guaranteeing
> 
> That's because I was only asked to scratch the surface, because
> the subject that arose was the choice of integral types to suit
> particular requirements. Now we are on the topic of conforming
> to external storage formats, which is something else. You haven't
> requested a discussion of this topic before.

We'll, this was brought up in prior messages leading up to this
thread. Perhaps you missed that aspect but we are both on the
same track now. No matter, I see you have a complete grasp on
the situation now discussed.

> 
> Conforming to external data layout can be done in a highly portable way in C.
> It can also be done in non-portable ways which are usually faster.
> 
> Instead of useless talk, why don't we try the following game: you describe the
> storage layout, and I will demonstrate a maximally portable C example which can
> communicate with that layout. I will entertain you as long as you wish.
> 
> Perhaps you will emerge out of this better armed for situations in which
> you have to use C rather than some other preferred tool such as Ada.

Been there, done that in C.
Been there, still doing that in Ada, and with much less hassle.

Subsequent messages on this thread have gone through this exercise
so I'll refer to them instead of duplicating the effort (or asking
your to duplicate). Your solution, both described in abstract above
and in implementation detail in other messages involves conversions
between an artificial intermediate representation which bears no
resemblence to the required types into and out of a C structure
which only resembles the required items but do not conform to the
specifications of the type. With these three components (the
intermediary
type, the abstract type, and the conversion routines) you do solve
the problem is communications were involved. I note the amount of
code required to support this architecture (conversion routines).
I also note the three separate maintenance areas involved.
The target type specifies range, size, and layout. Size is maintained
in the intermediary type. Range is maintained in the abstract type
(at least as well as C can support it). And layout is maintained
in the conversion routines.

The same situation in Ada dispenses with the conversion routines
(and the associated execution cost AND life-cycle maintenance)
by building the structures to the exacting specifications of the
context. Hence the code remains portable and simple. I submit that
your solution, while it can work, is not simple. My maintenance
is localized to a groups of type declarations and representation
clauses, all of which read very naturally compared to the type
specification itself.

To reimplement your solution in Ada, I simply declare a base
type sans representation clauses and declare derived types
from the base type and apply the necessary representation
clauses for the various type specifications I required.
This allows the compiler to use a most efficient layout
for the base (which I can manipulate as the abstract type).
I can then use simple Ada type conversions (without writting
a single line of supporting code) to convert from one layout
to another. In fact, my current project has a group which
passes hardware data around. We have the actual hardware
to deal with, and a hardware simulator produced by a third
part to deal with. Unfortunately, then don't used exactly
the same layout (how the third party got away with that
snafu is beyond me). We employ the method I have describe
and presto, no hassel and no worries.

I also submit that your solution does not support singleton access
to the fields. Your solution works when the goal is communications.
I get a packet, access and manipulate, and possible resent the packet.
Your solution does not work when the structure must reside on top of
a memory-mapped hardware location. In general, I CANNOT decode the whole
packet at once NOR can I decode the entire packet when I'm done. Some
hardware interfaces are sensitive to not only what I place in memory,
but if I place anything in memory. Bit splillage and extra access are
not allowed. Again, the Ada allows me to not only layout the type as
required, but also overlay the variable where it needs to be. Because
the type naturally maps to the desired representation, I can read/write
only the fields I need as the situation required. I invite you to extend
your solution to support singleton read/write access to each field of
the
structure. I know it can be done, but how much more code do you have to
write,
how many more points of maintenance are introduced, how much more
execution
penaly do is incured, how much more risk of failure is involved.

> 
> >products with custom code. C simply does not have the
> >language features to support any but the most
> >rudimentary porting requirements of single-machine,
> >black-box applications that run by themselves or
> >with others in a strictly homogeneous environment
> >all of which are built with a strictly compatible
> >set of tools.
> 
> That depends on what you mean by language features. If you mean that C
> doesn't have language features that are *specifically* designed to help you in
> this area, then you are right.

Which has been my point all along. Portability has little to do
with the needs of the application and everything to do with the
needs of the context. The context demands the code run in several
environment. This means portability of source code. It is becoming
increasing common for the context to also demand that code support
a particular type representation. At the risk of
repeating myself, portable code which cannot support specific
type representations is only portable in single-machine, black-box
applications that run by themselves _or_ with others in a strictly
homogenous (type consistent) environment all of which are built
with a strictly compatible (type consistent) set of tools. I submit
that those days are rapidly ending.

Even in the world of embedded and dedicated system, which are
traditionally written for a single target architecture, those days
are ending. More and more development of such system are preceeded
or are in parallel to efforts to simulate the system either for training
or verification. Reuse of code across all three areas is desirable to
cut costs. Usually, the training environment is vastly different from
the target environment and for verification, both environment must talk
to each other. Hence, the "real" code must conform to the target's
representation of things and the "fake" code (for training/simulation)
must also conform especially when used with "real" hardware for
verification.
Such situations are becoming more the norm than the exception
so any discussion of portability, which enables reuse, must
consider portable specification of contextually determined
type representations.

Finally, on the "real" target, I can ill-aford the extra time
and risk of using conversion routines due to the real-world
time response/latency requirements. Given the frequency such
conversion take place, the "fake" target also can ill-aford
conversion routines because the simulator is doing so many other
things to support training and verification that I quickly run out
of CPU horsepower no matter how big my computers. Bigger computers
just mean bigger simulations, not more resources for supporting
activities.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Porting Experiences (was Ada and Pascal etc )

[Peter Seebach]

In article <34638433.31EE@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
>As to rats'-nests, the worst rats' nests that I've seen have been BAIC
>and C programs.

The all time worst rats' nest I've ever seen goes to a program that you
could *claim* was C++, but honestly, at my most hostile to the language,
I wouldn't blame it on C++.

It was written by FORTRAN programmers.

The "List" class had one, and only one, virtual function; it was
called "Draw".  The only thing which implemented it was four or five
levels down an inheritance tree, and used it to draw only one kind
of object, with a large set of assumptions about which displays were
available to draw in.  Luckily, it was only called in these cases,
at least, by intent.

That wasn't the worst, it was just one of the most memorable pieces.

I had a lot of fun staring at that code and wondering what posessed
these people to do what they did.  It was pretty crazy.

-s
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <640ena$1q8@mtinsc04.worldnet.att.net>,
Craig Franck  <clfranck@worldnet.att.net> wrote:
>Show me a macro assembler that's more maintainable than C. (I 
>currently have MASM 6.1 and several hundred megabytes of C and
>asm code on my system that proves you wrong.)

You forgot to mention that 90% of the assembly won't even assemble.

Heh heh.
-- 
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
	-- Blair P. Houghton

Re: Porting Experiences (was Ada and Pascal etc )

[Vesa Karvonen]

Kaz Kylheku wrote:
> In article <640ena$1q8@mtinsc04.worldnet.att.net>,
> Craig Franck  <clfranck@worldnet.att.net> wrote:
> >Show me a macro assembler that's more maintainable than C. (I
> >currently have MASM 6.1 and several hundred megabytes of C and
> >asm code on my system that proves you wrong.)
> 
> You forgot to mention that 90% of the assembly won't even assemble.

He also forgot to mention that 90% of C programs invoke undefined
behaviour.

> Heh heh.

Ditto.

-- 
<-->
  Vesa Karvonen                |   If I were speaking for my
  Housemarque Games, Inc.      |   employer, you would not be
  http://www.housemarque.com   |   reading this...

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>Craig Franck wrote:
>> 
>> "Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>> >Craig Franck wrote:
>> 
>> >Second, if you are using a modern
>> >assembler with a decent macro processor, the assembler code is likely to
>> >be more maintainable than C code as well
>> 
>> That's silly. (You been hanging out with SN?)
>
>It's not silly, it's true. "Saying "that's silly" instead of presenting
>your ervidence, if any, is what's silly.  

What evidence do you want? Saying a modern assembler with a decent
macro processor is likely to produce code that is more maintainable
than C is simply false. If someone came to me and said they wanted
to do a project in Microsoft's latest incarnation of MASM, rather 
than C, because that would make the project more maintainable, I
would question their competence. [Not wanting to put words in your
mouth: you may replace MASM with any other macro assembler.]

>And I have no idea who SN is.

Scott Nudds (aka assembly boy, and a lot worse) of PASM fame.

>> >(yes, I know that it won't be
>> >as tight as hand coded one-for-one, but that doesn't bother me.)
>> 
>> By the time you have a macro assembler as maintainable as C, you
>> would have implemented a compiler. At which point using it would
>> be silly, because C is more portable.
>
>Trying to pur words in my mouth is what's silly here; I never claimed
>that the assembler code was portable, just more maintainable. 

Show me a macro assembler that's more maintainable than C. (I 
currently have MASM 6.1 and several hundred megabytes of C and
asm code on my system that proves you wrong.)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Dennis Weldy]

Go check DejaNews. Restrict yourself to the comp.lang.asm.x86, comp.lang.c,
and comp.lng.c++ newsgroups. Look for messages by "Scott Nudds".

Really a quite unique induhvidual.

Dennis
Shmuel (Seymour J.) Metz wrote in message <346382BD.25F8@gsg.eds.com>...
>Craig Franck wrote:
>>
>> "Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>> >Craig Franck wrote:
>>
>> >Second, if you are using a modern
>> >assembler with a decent macro processor, the assembler code is likely to
>> >be more maintainable than C code as well
>>
>> That's silly. (You been hanging out with SN?)
>
>It's not silly, it's true. "Saying "that's silly" instead of presenting
>your ervidence, if any, is what's silly.  And I have no idea who SN is.
>
>> >(yes, I know that it won't be
>> >as tight as hand coded one-for-one, but that doesn't bother me.)
>>
>> By the time you have a macro assembler as maintainable as C, you
>> would have implemented a compiler. At which point using it would
>> be silly, because C is more portable.
>
>Trying to pur words in my mouth is what's silly here; I never claimed
>that the assembler code was portable, just more maintainable.
>
>--
>
>                        Shmuel (Seymour J.) Metz
>                        Senior Software SE
>
>The values in from and reply-to are for the benefit of spammers:
>reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
>user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Dennis Weldy wrote:
> 
> Go check DejaNews. Restrict yourself to the comp.lang.asm.x86, comp.lang.c,
> and comp.lng.c++ newsgroups. Look for messages by "Scott Nudds".

Thanks; I found a lot of posts from him in scientific news groups, but
all that I found in the comp.* hierarchy were messages about him. There
seem to be a lot of messages making catty remarks about him, but very
little background on what he did to provoke them. OTOH, with 1540 hits
there was no way that I could read all of them :-(

BTW, did something happen to him recently? I saw some references to him
in the past tense, but didn't see an obit.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Dennis Weldy]

He pretty much disappeared. No idea if anything happened.

IMO, in the general case, the code produced with an HLL will be a bit more
maintaibale and easier to understand than equivalent Assembly. That said,
it's lso possible to write obscure, unmaintainable code in any language.
Straight Assembly will typically have one too busy looking at individual
pieces of bark, let alone being able to see a tree (or forest). That's not
to say that its not possible:-)

Further, if one is using assembly to get max speed, you'll use the
associated tools to do so. Using a "nonobvious" instruction sequence to
avoid pileline stalls, AGI locks, what have you.

At the HLL level, one usually doesn't have that. And y'can usually see
things at a bit higher level.
A bt easier to see whats going on as the amount of information per line of
code is typically higher.

Just my views. Counterexamples welcome :-)

Dennis

Shmuel (Seymour J.) Metz wrote in message <3467828E.1059@gsg.eds.com>...
>Dennis Weldy wrote:
>>
>> Go check DejaNews. Restrict yourself to the comp.lang.asm.x86,
comp.lang.c,
>> and comp.lng.c++ newsgroups. Look for messages by "Scott Nudds".
>
>Thanks; I found a lot of posts from him in scientific news groups, but
>all that I found in the comp.* hierarchy were messages about him. There
>seem to be a lot of messages making catty remarks about him, but very
>little background on what he did to provoke them. OTOH, with 1540 hits
>there was no way that I could read all of them :-(
>
>BTW, did something happen to him recently? I saw some references to him
>in the past tense, but didn't see an obit.
>
>--
>
>                        Shmuel (Seymour J.) Metz
>                        Senior Software SE
>
>The values in from and reply-to are for the benefit of spammers:
>reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
>user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Craig Franck wrote:
 
> What evidence do you want? Saying a modern assembler with a decent
> macro processor is likely to produce code that is more maintainable
> than C is simply false. 

ROTF,LMAO. It's the code produced by the programmer that is at issue,
not what is generated by the compiler. If you are in the habbit of
changing the output of your compiler in order to "save recompilation"
time, then it is past time for you to move into the 20th century.

> If someone came to me and said they wanted
> to do a project in Microsoft's latest incarnation of MASM, rather
> than C, because that would make the project more maintainable, I
> would question their competence. [Not wanting to put words in your
> mouth: you may replace MASM with any other macro assembler.]

If the only macro assembler that you know is MASM, then I question your
competence to address the issue.

> Show me a macro assembler that's more maintainable than C. (I
> currently have MASM 6.1 and several hundred megabytes of C and
> asm code on my system that proves you wrong.)

It proves nothing but the limitations of your background. It's not so
much that C and MASM is all you know, it's that you don't understand
that not all assemblers are the same and that not all programs in the
same language are the same. I'm willing to take your word for it the the
code you wrote in MASM is unmaintainable, but that says nothing about
code written by others or about code written for other asemblers.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>Craig Franck wrote:
> 
>> What evidence do you want? Saying a modern assembler with a decent
>> macro processor is likely to produce code that is more maintainable
>> than C is simply false. 
>
>ROTF,LMAO. It's the code produced by the programmer that is at issue,
>not what is generated by the compiler. 

I meant the source code the programmer would produce using those
two tools. (I was a bit ambiguous with my phrasing.)

>If you are in the habbit of
>changing the output of your compiler in order to "save recompilation"
>time, then it is past time for you to move into the 20th century.

Why, were they doing that in the 19th century. :-)

>> If someone came to me and said they wanted
>> to do a project in Microsoft's latest incarnation of MASM, rather
>> than C, because that would make the project more maintainable, I
>> would question their competence. [Not wanting to put words in your
>> mouth: you may replace MASM with any other macro assembler.]
>
>If the only macro assembler that you know is MASM, then I question your
>competence to address the issue.

I like MASM.

>> Show me a macro assembler that's more maintainable than C. (I
>> currently have MASM 6.1 and several hundred megabytes of C and
>> asm code on my system that proves you wrong.)
>
>It proves nothing but the limitations of your background. 

Then suggest a better macro assembler. Please, *do* enlighten.

>It's not so
>much that C and MASM is all you know, it's that you don't understand
>that not all assemblers are the same and that not all programs in the
>same language are the same. 

Every one of those points you just made is false.

>I'm willing to take your word for it the the
>code you wrote in MASM is unmaintainable, 

I never said it was unmaintainable; it's very good code. The code I
got from that Len Dorfman fellow and dozens of others is very good.

>but that says nothing about
>code written by others or about code written for other asemblers.

Only a very small fraction of the code on my system was written by 
me. It would be helpful if you would post a small snippet (or e-mail
me with more) of macro assembler source code that you feel is more
maintainable than when coded in a HLL like C. 

[If your reading comp.lang.c you can drop the .ada and .c++ groups.]

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Craig Franck wrote:
 
> I meant the source code the programmer would produce using those
> two tools. (I was a bit ambiguous with my phrasing.)

Well, if that's what you meant, I've got decades of experiences in a lot
of languages. The languages that have a good macro facility have an 
dvantage for applications where you need to supply complicated initial 
alues, since you can write a macro to automate the dirty work. Still 
mportant, but less so, is the generation of conditional code based on 
yntactical tests, e.g., number of arguments.

> Why, were they doing that in the 19th century. :-)

Hyerbole; sometimes I say "Before the fool, and I'm quite certain that 
old man Noach wasn't building computers with that gopher wood. ;-)

> >If the only macro assembler that you know is MASM, then I question your
> >competence to address the issue.
> 
> I like MASM.

It has its good points, but there are wide variations among assemblers, 
and unless you've seen a number of them then you have no basis to
discuss 
assemblers in general, only the ones that you've seen. 
 
> Then suggest a better macro assembler. Please, *do* enlighten.

Well, the most widely available one is the IBM High Level Assembler 
don't blame me; I didn't pick the name.)
 
> >It's not so
> >much that C and MASM is all you know, it's that you don't understand
> >that not all assemblers are the same and that not all programs in the
> >same language are the same.
> 
> Every one of those points you just made is false.

Perhaps, but your message certainly suggested that you have a very 
limited language background, and you haven't presented any reasons for
me to believe that it's wrong.

BTW, to answer a few last questions, I'm reading this on comp.lang.ada 
and I don't have access to any of my old source code or that of my 
colleagues. What's worse, there's stuff that I wouldn't be allowed to 
post even if I had access. Yeah, I know that I'm not the only one with 
that last problem :-( but I grew up in a culture of freely exchanging 
code and miss it.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Dennis Weldy wrote:
> 
> He pretty much disappeared. No idea if anything happened.

Thanks.
 
> IMO, in the general case, the code produced with an HLL will be a bit more
> maintaibale and easier to understand than equivalent Assembly. That said,
> it's lso possible to write obscure, unmaintainable code in any language.

Don't I know it! My language of choice is PL/I, but I've seen some PL/I
code
that shouldn't happen to a dog. And yes, it takes a little bit more
thought 
to write maintainable assembler code.

> Straight Assembly will typically have one too busy looking at individual
> pieces of bark, let alone being able to see a tree (or forest). That's not
> to say that its not possible:-)

Well, my assembler code makes heavy use of macros; I go for
maintainablity 
and readability, even at the price of speed. 
 
> Further, if one is using assembly to get max speed, you'll use the
> associated tools to do so. Using a "nonobvious" instruction sequence to
> avoid pileline stalls, AGI locks, what have you.

IMHO anyone who uses nonobvious instruction sequences is obligated to
comment
them adequately, even if that means writing a page or two of comments
for a 
single instruction. Remeber that "hacker" derives form "hack", as in "He 
doesn't play chess, he just hacks at it." I have nothing but contempt
for the 
idea that deliberately obscure code is a good thing in a production
program.
If you do something subtle, document it!
 
> At the HLL level, one usually doesn't have that. And y'can usually see
> things at a bit higher level.

I've seen the same sort of code in HLL, and I have the same attitude for
them:
the programmer is obligated to do whatever it takes to make the code 
understandable.

> A bt easier to see whats going on as the amount of information per line of
> code is typically higher.

Well, you said "typically", and I won't argue with that. I know a number
of 
languages, and mix and match depending on what is available and on the
nature
of the application. Typically I only use assembler for things that are 
awkward in other languages. 

One common example is generation of initial values. The macro facilities
of HLA and PL/I make those languages much better for generating
complicated data 
structures than the available alternatives.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Samuel T. Harris]

Steve Summit wrote:
> 

snip a whole lot of stuff I can't argue with...

> 
> And don't get me wrong: I do agree that, as bad an idea as it
> often is, the need to perform layout-constrained I/O can be very
> real.  If I were designing a language, I'd include features to
> make it more convenient.  But that's another story.
> 
> > So, I can't say to Kaz that he is wrong, because he is not, as far as
> > he goes. What I do say to Kaz is "You have only pricked the tip of the
> > portability iceberg." Portability involves much more than guaranteeing...
> 
> Well, it all depends on how you define "portability."  I've been
> a student of portability for a long time, and maybe I'm crazy or
> tilting at windmills off in left field, but I'd say that if you
> really care about portability, you need to define your data file
> formats portably, too.  If your data format is defined, either
> explicitly or implicitly, as containing fields such as "a 32-bit
> integer in the machine's byte order", then it's an inherently
> unportable format, and to describe a "portable" program for
> reading or writing this format is an oxymoron.
> 
> Once you've defined a portable data file format, *then* you can
> start arguing about which language makes it more or less
> convenient, or more or less efficient, to read and write that
> format.  But defining "portability" as the ability to write code
> which reads and writes binary formats and which recompiles
> anywhere, and then criticizing a language which does not make
> this task maximally convenient, strikes me as erecting a bit of a
> strawman.
> 
>                                         Steve Summit
>                                         scs@eskimo.com

Just to clarify. I agree completely that file format over which
I have control will be defined in a "portable" manner. However,
many times the context of the applications forces me to use
file formats, parameter types, etc. which are externally defined.
In the simulation world, they are usually defined to take advantage
of the idiosyncracies of target/embedded hardware which I have to
simulate/interface to with wholly incompatible hardware. In those
cases, I just don't have a choice.

I take an exception at the bit about "erecting a bit of a strawman".
Any language which is more convenient in a problem domain is a
superior choice over other, less convenient languages. "Language
wars" are not won or lost of singleton point such as our discussion
on portability (and the various flavors that involves) because
each projects have several of these problem domains with which
to deal. Each project has to take an aggregation of specific
considerations, each of which may or may not have a clear winner,
and decide what the primary language will be.

This sub-thread is about a particular problem domain. IMHO the
clear winner is Ada because of the convenience, lack of required
supported code, lower initial development, and lower maintenance.
But that only applies to this particular problem domain.
Add this comparison to your checklist and move on.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Porting Experiences (was Ada and Pascal etc )

[Steve Summit]

In article <3460A7BB.3CCD27DC@hso.link.com>,
Samuel T. Harris <s_harris@hso.link.com> evidently wrote:
> Reading the arguments between Kaz and others, I'm struck with the
> realization that Kaz is missing a significant point. As long as
> application code is not concerned with the representation of
> variables, Kaz is correct in his statements that a few simple
> guidelines insure good type choices for portable C code. What Kaz has
> failed to consider, but has been state by others, is that sometimes
> the representation of the type IS important to the application...
> context in which the application is running...  While application
> usually are only concerned witht he RANGE supported by the type...
> the context in which the app is running may force the use of
> [some type], especially when interfacing to hardware, COTS libraries,
> or in a distributed environment where heterogenous architectures must
> interface with each other. These are common examples of the context
> forcing a representation.  C does not support forcing the
> representation in a portable way. Ada does. The need for such
> cannot be simply dismissed because the need is real.

The need is as real as you make it.  (But note also that to
suggest that a problem be solved by avoiding it is not dismissing
or ignoring the problem.)

It's no surprise that performing portable, "binary" I/O to an
externally-imposed storage layout is less convenient in C.
*Everything* is less convenient in C!  It's a relatively
low-level language, as high-level languages go, and it embodies a
cornerstone of the Unix philosophy, which is that it should not
go too far in helping you to do something, because to help you to
do it invariably involves constraining the way you'll do it.
C lets you do I/O however you want; the cost is that you have
to specify more of the details to get what you want.

Of course, you can try to come up with a higher-level scheme
which contains so much flexibility that it lets you do whatever
you want, but of course, there are potential costs here, too.
One is the specification and implementation cost, and another is
the learning curve cost on the part of the would-be programmer.
From what you say, it sounds like Ada does attempt to tackle this
problem, but we know that at least one of those costs has already
been exacted.  For the first several years of its existence as a
language, Ada managed to revive an old adage from the earliest
days of high-level languages: Ada compilers were (just as FORTRAN
compilers were once thought to be) nearly impossible programs to
write.

I think that every aspect of this discussion over the problems of
performing portable, "binary" I/O is wholly consistent with the
established fact that C is a low-level language which may make
you do more work up-front than do more ambitious languages.
C's enduring popularity in spite of this tradeoff suggests
strongly that it must have some compensating merits.

But I've lapsed into silly, defensive, language-war posturing,
which is just that: silly!  Use the right tool for the job!
If you have an absolute requirement to perform I/O in a
byte-for-byte way to conform with externally-imposed storage
layouts, fread() and fwrite() are not your tools.  Either write
your own low-level I/O routines (as Kaz has been suggesting all
along), or use preexisting libraries such as those for XDR, CDF,
or HDF, or use another language which either has I/O built in or
makes it easier to encapsulate your own.  Don't blame C or call
it a poor tool for not making it easier to perform this task;
blame yourself or your superiors for choosing a poor tool or a
poor strategy.

And don't get me wrong: I do agree that, as bad an idea as it
often is, the need to perform layout-constrained I/O can be very
real.  If I were designing a language, I'd include features to
make it more convenient.  But that's another story.

> So, I can't say to Kaz that he is wrong, because he is not, as far as
> he goes. What I do say to Kaz is "You have only pricked the tip of the
> portability iceberg." Portability involves much more than guaranteeing...

Well, it all depends on how you define "portability."  I've been
a student of portability for a long time, and maybe I'm crazy or
tilting at windmills off in left field, but I'd say that if you
really care about portability, you need to define your data file
formats portably, too.  If your data format is defined, either
explicitly or implicitly, as containing fields such as "a 32-bit
integer in the machine's byte order", then it's an inherently
unportable format, and to describe a "portable" program for
reading or writing this format is an oxymoron.

Once you've defined a portable data file format, *then* you can
start arguing about which language makes it more or less
convenient, or more or less efficient, to read and write that
format.  But defining "portability" as the ability to write code
which reads and writes binary formats and which recompiles
anywhere, and then criticizing a language which does not make
this task maximally convenient, strikes me as erecting a bit of a
strawman.

					Steve Summit
					scs@eskimo.com

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>Craig Franck wrote:

>> Then suggest a better macro assembler. Please, *do* enlighten.
>
>Well, the most widely available one is the IBM High Level Assembler 
>don't blame me; I didn't pick the name.)

I will see what I can find out about it.
 
>> >It's not so
>> >much that C and MASM is all you know, it's that you don't understand
>> >that not all assemblers are the same and that not all programs in the
>> >same language are the same.
>> 
>> Every one of those points you just made is false.
>
>Perhaps, but your message certainly suggested that you have a very 
>limited language background, and you haven't presented any reasons for
>me to believe that it's wrong.

I can only dispell so many assumptions a day! :-)

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Robert Munck]

On Wed, 12 Nov 1997 17:52:04 -0800, "Shmuel (Seymour J.) Metz"
<nospam@gsg.eds.com> wrote:

>
>Well, my assembler code makes heavy use of macros; I go for
>maintainablity and readability, even at the price of speed. 

Does anyone doing assembler use IF...THEN and other 
structured programming macros anymore? I wrote some
pretty complex macro definitions for IBM's Assembler F
about 30 years ago, and then wrote a post-processor
for the listing file that indented the code appropriately,
supressed the macro expansions for the structure
macros while leaving others intact, and did other
pretty-printing functions.  Harlan Mills borrowed
my definitions and publicized them.

Bob Munck
Mill Creek Systems LC

Re: Porting Experiences (was Ada and Pascal etc )

[Ralph Silverman]

Shmuel (Seymour J.) Metz (nospam@gsg.eds.com) wrote:
: Craig Franck wrote:
:  
: > I meant the source code the programmer would produce using those
: > two tools. (I was a bit ambiguous with my phrasing.)

: Well, if that's what you meant, I've got decades of experiences in a lot
: of languages. The languages that have a good macro facility have an 
: dvantage for applications where you need to supply complicated initial 
: alues, since you can write a macro to automate the dirty work. Still 
: mportant, but less so, is the generation of conditional code based on 
: yntactical tests, e.g., number of arguments.

: > Why, were they doing that in the 19th century. :-)

: Hyerbole; sometimes I say "Before the fool, and I'm quite certain that 
: old man Noach wasn't building computers with that gopher wood. ;-)

: > >If the only macro assembler that you know is MASM, then I question your
: > >competence to address the issue.
: > 
: > I like MASM.

: It has its good points, but there are wide variations among assemblers, 
: and unless you've seen a number of them then you have no basis to
: discuss 
: assemblers in general, only the ones that you've seen. 
:  
: > Then suggest a better macro assembler. Please, *do* enlighten.

: Well, the most widely available one is the IBM High Level Assembler 
: don't blame me; I didn't pick the name.)
:  
: > >It's not so
: > >much that C and MASM is all you know, it's that you don't understand
: > >that not all assemblers are the same and that not all programs in the
: > >same language are the same.
: > 
: > Every one of those points you just made is false.

: Perhaps, but your message certainly suggested that you have a very 
: limited language background, and you haven't presented any reasons for
: me to believe that it's wrong.

: BTW, to answer a few last questions, I'm reading this on comp.lang.ada 
: and I don't have access to any of my old source code or that of my 
: colleagues. What's worse, there's stuff that I wouldn't be allowed to 
: post even if I had access. Yeah, I know that I'm not the only one with 
: that last problem :-( but I grew up in a culture of freely exchanging 
: code and miss it.

: -- 

:                         Shmuel (Seymour J.) Metz
:                         Senior Software SE

: The values in from and reply-to are for the benefit of spammers:
: reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
: user smetz. Do not reply to spamtrap@library.lspace.org


	very good macro facility is found
	with
		eric isaacson 's
		a86 d86
	( pc assembler,  debugger )
	shareware
	^^^^^^^^^
	( widely available ... )
	...

--

Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us