* Re: Porting Experiences (was Ada and Pascal etc )
@ 1997-11-03 0:00 Marin David Condic, 561.796.8997, M/S 731-96
1997-11-04 0:00 ` Jerry van Dijk
0 siblings, 1 reply; 60+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1997-11-03 0:00 UTC (permalink / raw)
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
===============================================================================
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-03 0:00 Porting Experiences (was Ada and Pascal etc ) Marin David Condic, 561.796.8997, M/S 731-96 @ 1997-11-04 0:00 ` Jerry van Dijk 0 siblings, 0 replies; 60+ messages in thread From: Jerry van Dijk @ 1997-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc )
@ 1997-11-06 0:00 Marin David Condic, 561.796.8997, M/S 731-96
0 siblings, 0 replies; 60+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1997-11-06 0:00 UTC (permalink / raw)
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
===============================================================================
^ permalink raw reply [flat|nested] 60+ messages in thread
* ADA SUCKS, C/C++/JAVA RULES!!!! @ 1997-10-28 0:00 John Black 1997-10-28 0:00 ` John Black 0 siblings, 1 reply; 60+ messages in thread From: John Black @ 1997-10-28 0:00 UTC (permalink / raw) I have tried and tried to program with Ada, but it is downright impossible. I just don't see how anyone could - or would want to - use this outdated piece of crap. It's back to C++ and Java for me. Hopefully Ada and other languages will go the way of the dinosaur and get hit by a meteor, disappearing from the face of the earth. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: ADA SUCKS, C/C++/JAVA RULES!!!! 1997-10-28 0:00 ADA SUCKS, C/C++/JAVA RULES!!!! John Black @ 1997-10-28 0:00 ` John Black 1997-10-28 0:00 ` ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Black 0 siblings, 1 reply; 60+ messages in thread From: John Black @ 1997-10-28 0:00 UTC (permalink / raw) You guys say what you want but it's true. ADA is good for nothing. C++, on the other hand, is the only language you need. ^ permalink raw reply [flat|nested] 60+ messages in thread
* ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! 1997-10-28 0:00 ` John Black @ 1997-10-28 0:00 ` John Black 1997-10-28 0:00 ` David A. Frantz 0 siblings, 1 reply; 60+ messages in thread From: John Black @ 1997-10-28 0:00 UTC (permalink / raw) ADA and Pascal are two of the most useless inventions Man has ever wasted space on this planet with. These languages are hard to learn, have zero applications, and people who only know these languages can only find jobs at Taco Bell! Smart programmers spend their time learning only C, C++, and Java in that order. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! 1997-10-28 0:00 ` ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Black @ 1997-10-28 0:00 ` David A. Frantz 1997-10-29 0:00 ` John Black 0 siblings, 1 reply; 60+ messages in thread From: David A. Frantz @ 1997-10-28 0:00 UTC (permalink / raw) ADA and Pascal hard to learn he he. Just how many programmers out there have a handle on C++. The whole package; STL, IOstreams, Class, Templates - I could go on and on but the point is that there are only a handful of people out there with a complete understanding of C++. Then there is the Question of how many of those are actually productive with it. If C++ is that simple then we should be able to find VALIDATED compilers on the market, far as I Know there is none out there. The problem with ADA is that it is rejected by the hacker cult that started out on C. Mean while C & C++ have been rejected by anybody who has to ship a product under tight deadlines and high quality expectations. i.e. anyone working for a corporation. Dave John Black wrote in message <345673af.1413708@news.mindspring.com>... >ADA and Pascal are two of the most useless inventions Man has ever >wasted space on this planet with. These languages are hard to learn, >have zero applications, and people who only know these languages can >only find jobs at Taco Bell! Smart programmers spend their time >learning only C, C++, and Java in that order. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! 1997-10-28 0:00 ` David A. Frantz @ 1997-10-29 0:00 ` John Black 1997-10-29 0:00 ` Mike Copeland 0 siblings, 1 reply; 60+ messages in thread From: John Black @ 1997-10-29 0:00 UTC (permalink / raw) Then why do the want ads for C, C++ programmers could stretch from here to the moon, while Ada/Pascal programmers are nonexistent? Like I said, if you program in Ada or Pascal, your best job is going to be taking orders at Red Lobster. >The problem with ADA is that it is rejected by the hacker cult that started >out on C. Mean while C & C++ have been rejected by anybody who has to >ship a product under tight deadlines and high quality expectations. i.e. >anyone working for a corporation. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! 1997-10-29 0:00 ` John Black @ 1997-10-29 0:00 ` Mike Copeland 1997-10-31 0:00 ` Alan E & Carmel J Brain 0 siblings, 1 reply; 60+ messages in thread From: Mike Copeland @ 1997-10-29 0:00 UTC (permalink / raw) This has almost nothing to do with the "ease of learning" either language (and I feel C/C++ is much harder to do so than Pascal), but by some other factors: 1. The portability issue. C/C++ are basically portable across platforms, and this is an extremely important issue to corporate thinking. It's more important to the executives/decision makers of most companies that their key applications can be moved to other vendor's hardware when financial issues force such switches, than to have implementation languages which their programmers like and find easy to learn. 2. Pascal and Ada (which is often called a highly enriched Pascal) weren't designed as application development vehicles - whereas C/C++ were. Pascal was invented as a teaching tool for structured and module problem solving, to show and overcome the faults of weakly typed and inherently undisciplined coding languages of the past (e.g. COBOL, ForTran, BASIC, assembler, etc.). There was almost no thought given to I/o, databases, strings, and performance issues with Wirth's Pascal, and he designed the language to teach the initial concepts of program correctness, and modular design. It wasn't until Borland marketed Turbo Pascal (which they didn't initially write) that Pascal became a real implementation tool, instead of the "teaching toy" it really was. However, Pascal is almost non-existent in the business environment, regardless of how many hobbiests and PC programmers make effective use of it....sigh Ada, OTOH, was designed for implementation of secure and fail-safe systems for the Government. It was based on Pascal concepts (very strong typing, modularity, consistency, etc.), but was taken much farther than was useful to the general world. Learning Ada should be considered an educational experience, at best, because no one uses it. And I agree it's very hard to learn and work with, even coming from a Pascal background. Nonetheless, Ada provides some interesting and useful things for any serious programmer to think about and use in his/her work. > Then why do the want ads for C, C++ programmers could stretch from > here to the moon, while Ada/Pascal programmers are nonexistent? Like > I said, if you program in Ada or Pascal, your best job is going to be > taking orders at Red Lobster. > > >The problem with ADA is that it is rejected by the hacker cult that started > >out on C. Mean while C & C++ have been rejected by anybody who has to > >ship a product under tight deadlines and high quality expectations. i.e. > >anyone working for a corporation. > ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! 1997-10-29 0:00 ` Mike Copeland @ 1997-10-31 0:00 ` Alan E & Carmel J Brain 1997-10-30 0:00 ` Jon S Anthony 0 siblings, 1 reply; 60+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-31 0:00 UTC (permalink / raw) Mike Copeland wrote: > > This has almost nothing to do with the "ease of learning" either > language (and I feel C/C++ is much harder to do so than Pascal), but by > some other factors: > 1. The portability issue. C/C++ are basically portable across > platforms, and this is an extremely important issue to corporate > thinking. While I agree with most of your post, I must take issue here. C and C++ are perceived as being portable. Inasmuch as there are almost no major computers which don't have a C or C++ compiler, this is true. And that's a big, big selling point. However.... C and C++ compilers differ by so much that porting is often a Nightmare. Before I get flamed, I'd like to talk to people who've actually ported code cross-platform. In my own, albeit limited experience, the problems I've had with any C or C++ port are greater than all the problems I've had with Ada crossplatform put together! If you have an Ada compiler by brand A on target X, the same code has a high probability of being correct out-of-the-box by brand B on target X, and will often work with brand C on target Y. Example: 15,000 LOCs originally written on an IBM-386 using Thomson (now Aonix) Ada-83, ported to a microVax running an Irvine compiler in Australia for checking, then transmitted to Germany to run on a microVax using DecAda, and finally using the Winterstein Compiler onto a KAV-30 embedded system. 3 lines of code had to be changed (in Australia). Due to bugs. Yes, this is an actual example, of a Knowledge-based real-time subsytem's components. Now C++ on the other hand, written using CodeWarrior 10 on a Mac, ported to CodeWarrior 10 on an IBM... or even MVC++ 4 vs MVC++ 5... or worse still CodeWarrior 9 on a Mac to CodeWarrior 10 on a Mac to MVC++ 5 on an IBM... In 15,000 LOCs of C++ how many would you reasonably expect to have to be changed? (yes, these were actual examples too) -- 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! 1997-10-31 0:00 ` Alan E & Carmel J Brain @ 1997-10-30 0:00 ` Jon S Anthony 1997-10-31 0:00 ` Craig Franck 0 siblings, 1 reply; 60+ messages in thread From: Jon S Anthony @ 1997-10-30 0:00 UTC (permalink / raw) Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes: > C and C++ compilers differ by so much that porting is often a Nightmare. > Before I get flamed, I'd like to talk to people who've actually ported > code cross-platform. That's about right. Porting anything of substance written in C even between compilers on the _same_ platform is depressing. FOE here... > In my own, albeit limited experience, the problems I've had with any > C or C++ port are greater than all the problems I've had with Ada > crossplatform put together! That rings true as well. Typically porting Ada code between platforms or compilers amounts to a recompilation. /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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! 1997-10-30 0:00 ` Jon S Anthony @ 1997-10-31 0:00 ` Craig Franck 1997-10-31 0:00 ` Jon S Anthony 0 siblings, 1 reply; 60+ messages in thread From: Craig Franck @ 1997-10-31 0:00 UTC (permalink / raw) Jon S Anthony <jsa@synquiry.com> wrote: >Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes: > >> C and C++ compilers differ by so much that porting is often a Nightmare. >> Before I get flamed, I'd like to talk to people who've actually ported >> code cross-platform. > >That's about right. Porting anything of substance written in C even >between compilers on the _same_ platform is depressing. FOE here... Sounds like you may have been a victim of the run of your patients. Well written C code is very portable. I've seen compiler upgrades break code, but only because it was trash to begin with. >> In my own, albeit limited experience, the problems I've had with any >> C or C++ port are greater than all the problems I've had with Ada >> crossplatform put together! > >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. -- 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! 1997-10-31 0:00 ` Craig Franck @ 1997-10-31 0:00 ` Jon S Anthony 1997-11-01 0:00 ` Porting Experiences (was Ada and Pascal etc ) Alan E & Carmel J Brain 0 siblings, 1 reply; 60+ messages in thread From: Jon S Anthony @ 1997-10-31 0:00 UTC (permalink / raw) Craig Franck <clfranck@worldnet.att.net> writes: > Jon S Anthony <jsa@synquiry.com> wrote: > >Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes: > > > >> C and C++ compilers differ by so much that porting is often a Nightmare. > >> Before I get flamed, I'd like to talk to people who've actually ported > >> code cross-platform. > > > >That's about right. Porting anything of substance written in C even > >between compilers on the _same_ platform is depressing. FOE here... > > Sounds like you may have been a victim of the run of your patients. > Well written C code is very portable. I've seen compiler upgrades > break code, but only because it was trash to begin with. Yes, I thnk I can agree with that. But the point is it is so _easy_ (though not as much with ANSI C) to write such trash. Even by "accident". > >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. /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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-10-31 0:00 ` Jon S Anthony @ 1997-11-01 0:00 ` Alan E & Carmel J Brain 1997-11-01 0:00 ` Jon S Anthony 1997-11-01 0:00 ` Craig Franck 0 siblings, 2 replies; 60+ messages in thread From: Alan E & Carmel J Brain @ 1997-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-01 0:00 ` Porting Experiences (was Ada and Pascal etc ) Alan E & Carmel J Brain @ 1997-11-01 0:00 ` Jon S Anthony 1997-11-01 0:00 ` Craig Franck 1 sibling, 0 replies; 60+ messages in thread From: Jon S Anthony @ 1997-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-01 0:00 ` Porting Experiences (was Ada and Pascal etc ) Alan E & Carmel J Brain 1997-11-01 0:00 ` Jon S Anthony @ 1997-11-01 0:00 ` Craig Franck 1997-11-03 0:00 ` Jon S Anthony ` (2 more replies) 1 sibling, 3 replies; 60+ messages in thread From: Craig Franck @ 1997-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-01 0:00 ` Craig Franck @ 1997-11-03 0:00 ` Jon S Anthony 1997-11-03 0:00 ` Alan E & Carmel J Brain 1997-11-03 0:00 ` Shmuel (Seymour J.) Metz 2 siblings, 0 replies; 60+ messages in thread From: Jon S Anthony @ 1997-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-01 0:00 ` Craig Franck 1997-11-03 0:00 ` Jon S Anthony @ 1997-11-03 0:00 ` Alan E & Carmel J Brain 1997-11-03 0:00 ` Shmuel (Seymour J.) Metz 2 siblings, 0 replies; 60+ messages in thread From: Alan E & Carmel J Brain @ 1997-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-01 0:00 ` Craig Franck 1997-11-03 0:00 ` Jon S Anthony 1997-11-03 0:00 ` Alan E & Carmel J Brain @ 1997-11-03 0:00 ` Shmuel (Seymour J.) Metz 1997-11-03 0:00 ` Kaz Kylheku ` (2 more replies) 2 siblings, 3 replies; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-03 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-03 0:00 ` Kaz Kylheku 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz ` (2 more replies) 1997-11-04 0:00 ` Lawrence Kirby [not found] ` <63m3pt$t2d@bgtnsc02.worldnet.att.net> 2 siblings, 3 replies; 60+ messages in thread From: Kaz Kylheku @ 1997-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-03 0:00 ` Kaz Kylheku @ 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Craig Franck 1997-11-04 0:00 ` Pat Rogers 1997-11-05 0:00 ` Samuel T. Harris 2 siblings, 2 replies; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Boyd Roberts 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz 1997-11-05 0:00 ` Craig Franck 1 sibling, 2 replies; 60+ messages in thread From: Kaz Kylheku @ 1997-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Kaz Kylheku @ 1997-11-05 0:00 ` Boyd Roberts 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 0 replies; 60+ messages in thread From: Boyd Roberts @ 1997-11-05 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Boyd Roberts @ 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 0 replies; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-04 0:00 ` Kaz Kylheku @ 1997-11-05 0:00 ` Craig Franck 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 1 reply; 60+ messages in thread From: Craig Franck @ 1997-11-05 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Craig Franck @ 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz 1997-11-06 0:00 ` Lawrence Kirby 1997-11-07 0:00 ` Craig Franck 0 siblings, 2 replies; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-06 0:00 ` Lawrence Kirby 1997-11-07 0:00 ` Boyd Roberts 1997-11-07 0:00 ` Craig Franck 1 sibling, 1 reply; 60+ messages in thread From: Lawrence Kirby @ 1997-11-06 0:00 UTC (permalink / raw) 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 ----------------------------------------- ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-06 0:00 ` Lawrence Kirby @ 1997-11-07 0:00 ` Boyd Roberts 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 1 reply; 60+ messages in thread From: Boyd Roberts @ 1997-11-07 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-07 0:00 ` Boyd Roberts @ 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz 1997-11-07 0:00 ` Peter Seebach 0 siblings, 1 reply; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-07 0:00 ` Peter Seebach 0 siblings, 0 replies; 60+ messages in thread From: Peter Seebach @ 1997-11-07 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz 1997-11-06 0:00 ` Lawrence Kirby @ 1997-11-07 0:00 ` Craig Franck 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 1 reply; 60+ messages in thread From: Craig Franck @ 1997-11-07 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-07 0:00 ` Craig Franck @ 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz 1997-11-08 0:00 ` Craig Franck 1997-11-09 0:00 ` Dennis Weldy 0 siblings, 2 replies; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-08 0:00 ` Craig Franck 1997-11-08 0:00 ` Kaz Kylheku 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz 1997-11-09 0:00 ` Dennis Weldy 1 sibling, 2 replies; 60+ messages in thread From: Craig Franck @ 1997-11-08 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-08 0:00 ` Craig Franck @ 1997-11-08 0:00 ` Kaz Kylheku 1997-11-08 0:00 ` Vesa Karvonen 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 1 reply; 60+ messages in thread From: Kaz Kylheku @ 1997-11-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-08 0:00 ` Kaz Kylheku @ 1997-11-08 0:00 ` Vesa Karvonen 0 siblings, 0 replies; 60+ messages in thread From: Vesa Karvonen @ 1997-11-08 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-08 0:00 ` Craig Franck 1997-11-08 0:00 ` Kaz Kylheku @ 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz 1997-11-11 0:00 ` Craig Franck 1 sibling, 1 reply; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-11 0:00 ` Craig Franck 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 1 reply; 60+ messages in thread From: Craig Franck @ 1997-11-11 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-11 0:00 ` Craig Franck @ 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz 1997-11-14 0:00 ` Craig Franck 1997-11-24 0:00 ` Ralph Silverman 0 siblings, 2 replies; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-14 0:00 ` Craig Franck 1997-11-24 0:00 ` Ralph Silverman 1 sibling, 0 replies; 60+ messages in thread From: Craig Franck @ 1997-11-14 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz 1997-11-14 0:00 ` Craig Franck @ 1997-11-24 0:00 ` Ralph Silverman 1 sibling, 0 replies; 60+ messages in thread From: Ralph Silverman @ 1997-11-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz 1997-11-08 0:00 ` Craig Franck @ 1997-11-09 0:00 ` Dennis Weldy 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 1 reply; 60+ messages in thread From: Dennis Weldy @ 1997-11-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-09 0:00 ` Dennis Weldy @ 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz 1997-11-10 0:00 ` Dennis Weldy 0 siblings, 1 reply; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-10 0:00 ` Dennis Weldy 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 1 reply; 60+ messages in thread From: Dennis Weldy @ 1997-11-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-10 0:00 ` Dennis Weldy @ 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz 1997-11-14 0:00 ` Robert Munck 0 siblings, 1 reply; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-14 0:00 ` Robert Munck 0 siblings, 0 replies; 60+ messages in thread From: Robert Munck @ 1997-11-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-03 0:00 ` Kaz Kylheku 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-04 0:00 ` Pat Rogers 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Samuel T. Harris 2 siblings, 1 reply; 60+ messages in thread From: Pat Rogers @ 1997-11-04 0:00 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Pat Rogers @ 1997-11-04 0:00 ` Kaz Kylheku 0 siblings, 0 replies; 60+ messages in thread From: Kaz Kylheku @ 1997-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-03 0:00 ` Kaz Kylheku 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-04 0:00 ` Pat Rogers @ 1997-11-05 0:00 ` Samuel T. Harris 1997-11-05 0:00 ` Kaz Kylheku 1997-11-13 0:00 ` Steve Summit 2 siblings, 2 replies; 60+ messages in thread From: Samuel T. Harris @ 1997-11-05 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Samuel T. Harris @ 1997-11-05 0:00 ` Kaz Kylheku 1997-11-06 0:00 ` Alan E & Carmel J Brain 1997-11-07 0:00 ` Samuel T. Harris 1997-11-13 0:00 ` Steve Summit 1 sibling, 2 replies; 60+ messages in thread From: Kaz Kylheku @ 1997-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Kaz Kylheku @ 1997-11-06 0:00 ` Alan E & Carmel J Brain 1997-11-06 0:00 ` Kaz Kylheku 1997-11-06 0:00 ` Paul Campbell 1997-11-07 0:00 ` Samuel T. Harris 1 sibling, 2 replies; 60+ messages in thread From: Alan E & Carmel J Brain @ 1997-11-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-06 0:00 ` Alan E & Carmel J Brain @ 1997-11-06 0:00 ` Kaz Kylheku 1997-11-06 0:00 ` Paul Campbell 1 sibling, 0 replies; 60+ messages in thread From: Kaz Kylheku @ 1997-11-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-06 0:00 ` Alan E & Carmel J Brain 1997-11-06 0:00 ` Kaz Kylheku @ 1997-11-06 0:00 ` Paul Campbell 1 sibling, 0 replies; 60+ messages in thread From: Paul Campbell @ 1997-11-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Kaz Kylheku 1997-11-06 0:00 ` Alan E & Carmel J Brain @ 1997-11-07 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 60+ messages in thread From: Samuel T. Harris @ 1997-11-07 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Samuel T. Harris 1997-11-05 0:00 ` Kaz Kylheku @ 1997-11-13 0:00 ` Steve Summit 1997-11-13 0:00 ` Samuel T. Harris 1 sibling, 1 reply; 60+ messages in thread From: Steve Summit @ 1997-11-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-13 0:00 ` Steve Summit @ 1997-11-13 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 60+ messages in thread From: Samuel T. Harris @ 1997-11-13 0:00 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-03 0:00 ` Shmuel (Seymour J.) Metz 1997-11-03 0:00 ` Kaz Kylheku @ 1997-11-04 0:00 ` Lawrence Kirby 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz [not found] ` <63m3pt$t2d@bgtnsc02.worldnet.att.net> 2 siblings, 1 reply; 60+ messages in thread From: Lawrence Kirby @ 1997-11-04 0:00 UTC (permalink / raw) 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 ----------------------------------------- ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Lawrence Kirby @ 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-04 0:00 ` Kaz Kylheku ` (4 more replies) 0 siblings, 5 replies; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Chris Brand 1997-11-07 0:00 ` Boyd Roberts 1997-11-05 0:00 ` Craig Franck ` (3 subsequent siblings) 4 siblings, 2 replies; 60+ messages in thread From: Kaz Kylheku @ 1997-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Kaz Kylheku @ 1997-11-05 0:00 ` Chris Brand 1997-11-05 0:00 ` Kaz Kylheku ` (3 more replies) 1997-11-07 0:00 ` Boyd Roberts 1 sibling, 4 replies; 60+ messages in thread From: Chris Brand @ 1997-11-05 0:00 UTC (permalink / raw) 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] | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Chris Brand @ 1997-11-05 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Kaz Kylheku ` (2 subsequent siblings) 3 siblings, 0 replies; 60+ messages in thread From: Kaz Kylheku @ 1997-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Chris Brand 1997-11-05 0:00 ` Kaz Kylheku @ 1997-11-05 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Lawrence Kirby 1997-11-05 0:00 ` Dann Corbit 3 siblings, 0 replies; 60+ messages in thread From: Kaz Kylheku @ 1997-11-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Chris Brand 1997-11-05 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Kaz Kylheku @ 1997-11-05 0:00 ` Lawrence Kirby 1997-11-05 0:00 ` Dann Corbit 3 siblings, 0 replies; 60+ messages in thread From: Lawrence Kirby @ 1997-11-05 0:00 UTC (permalink / raw) 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 ----------------------------------------- ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-05 0:00 ` Chris Brand ` (2 preceding siblings ...) 1997-11-05 0:00 ` Lawrence Kirby @ 1997-11-05 0:00 ` Dann Corbit 3 siblings, 0 replies; 60+ messages in thread From: Dann Corbit @ 1997-11-05 0:00 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Chris Brand @ 1997-11-07 0:00 ` Boyd Roberts 1 sibling, 0 replies; 60+ messages in thread From: Boyd Roberts @ 1997-11-07 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-04 0:00 ` Kaz Kylheku @ 1997-11-05 0:00 ` Craig Franck 1997-11-05 0:00 ` James Youngman ` (2 subsequent siblings) 4 siblings, 0 replies; 60+ messages in thread From: Craig Franck @ 1997-11-05 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Craig Franck @ 1997-11-05 0:00 ` James Youngman 1997-11-05 0:00 ` Lawrence Kirby 1997-11-05 0:00 ` Steve Summit 4 siblings, 0 replies; 60+ messages in thread From: James Youngman @ 1997-11-05 0:00 UTC (permalink / raw) To: smetz >>>>> "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. ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz ` (2 preceding siblings ...) 1997-11-05 0:00 ` James Youngman @ 1997-11-05 0:00 ` Lawrence Kirby 1997-11-05 0:00 ` Steve Summit 4 siblings, 0 replies; 60+ messages in thread From: Lawrence Kirby @ 1997-11-05 0:00 UTC (permalink / raw) 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 ----------------------------------------- ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz ` (3 preceding siblings ...) 1997-11-05 0:00 ` Lawrence Kirby @ 1997-11-05 0:00 ` Steve Summit 4 siblings, 0 replies; 60+ messages in thread From: Steve Summit @ 1997-11-05 0:00 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 60+ messages in thread
[parent not found: <63m3pt$t2d@bgtnsc02.worldnet.att.net>]
* Re: Porting Experiences (was Ada and Pascal etc ) [not found] ` <63m3pt$t2d@bgtnsc02.worldnet.att.net> @ 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-05 0:00 ` Craig Franck 0 siblings, 1 reply; 60+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Porting Experiences (was Ada and Pascal etc ) 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz @ 1997-11-05 0:00 ` Craig Franck 0 siblings, 0 replies; 60+ messages in thread From: Craig Franck @ 1997-11-05 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~1997-11-24 0:00 UTC | newest] Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-11-03 0:00 Porting Experiences (was Ada and Pascal etc ) Marin David Condic, 561.796.8997, M/S 731-96 1997-11-04 0:00 ` Jerry van Dijk -- strict thread matches above, loose matches on Subject: below -- 1997-11-06 0:00 Marin David Condic, 561.796.8997, M/S 731-96 1997-10-28 0:00 ADA SUCKS, C/C++/JAVA RULES!!!! John Black 1997-10-28 0:00 ` John Black 1997-10-28 0:00 ` ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Black 1997-10-28 0:00 ` David A. Frantz 1997-10-29 0:00 ` John Black 1997-10-29 0:00 ` Mike Copeland 1997-10-31 0:00 ` Alan E & Carmel J Brain 1997-10-30 0:00 ` Jon S Anthony 1997-10-31 0:00 ` Craig Franck 1997-10-31 0:00 ` Jon S Anthony 1997-11-01 0:00 ` Porting Experiences (was Ada and Pascal etc ) Alan E & Carmel J Brain 1997-11-01 0:00 ` Jon S Anthony 1997-11-01 0:00 ` Craig Franck 1997-11-03 0:00 ` Jon S Anthony 1997-11-03 0:00 ` Alan E & Carmel J Brain 1997-11-03 0:00 ` Shmuel (Seymour J.) Metz 1997-11-03 0:00 ` Kaz Kylheku 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Boyd Roberts 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz 1997-11-05 0:00 ` Craig Franck 1997-11-05 0:00 ` Shmuel (Seymour J.) Metz 1997-11-06 0:00 ` Lawrence Kirby 1997-11-07 0:00 ` Boyd Roberts 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz 1997-11-07 0:00 ` Peter Seebach 1997-11-07 0:00 ` Craig Franck 1997-11-07 0:00 ` Shmuel (Seymour J.) Metz 1997-11-08 0:00 ` Craig Franck 1997-11-08 0:00 ` Kaz Kylheku 1997-11-08 0:00 ` Vesa Karvonen 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz 1997-11-11 0:00 ` Craig Franck 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz 1997-11-14 0:00 ` Craig Franck 1997-11-24 0:00 ` Ralph Silverman 1997-11-09 0:00 ` Dennis Weldy 1997-11-10 0:00 ` Shmuel (Seymour J.) Metz 1997-11-10 0:00 ` Dennis Weldy 1997-11-12 0:00 ` Shmuel (Seymour J.) Metz 1997-11-14 0:00 ` Robert Munck 1997-11-04 0:00 ` Pat Rogers 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Samuel T. Harris 1997-11-05 0:00 ` Kaz Kylheku 1997-11-06 0:00 ` Alan E & Carmel J Brain 1997-11-06 0:00 ` Kaz Kylheku 1997-11-06 0:00 ` Paul Campbell 1997-11-07 0:00 ` Samuel T. Harris 1997-11-13 0:00 ` Steve Summit 1997-11-13 0:00 ` Samuel T. Harris 1997-11-04 0:00 ` Lawrence Kirby 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-04 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Chris Brand 1997-11-05 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Kaz Kylheku 1997-11-05 0:00 ` Lawrence Kirby 1997-11-05 0:00 ` Dann Corbit 1997-11-07 0:00 ` Boyd Roberts 1997-11-05 0:00 ` Craig Franck 1997-11-05 0:00 ` James Youngman 1997-11-05 0:00 ` Lawrence Kirby 1997-11-05 0:00 ` Steve Summit [not found] ` <63m3pt$t2d@bgtnsc02.worldnet.att.net> 1997-11-04 0:00 ` Shmuel (Seymour J.) Metz 1997-11-05 0:00 ` Craig Franck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox