By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,281 Members | 2,216 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,281 IT Pros & Developers. It's quick & easy.

C portability is a myth

P: n/a
I just read couple articles on this group and it keeps amazing me how
the portability is used as strong argument for language cleanliness.

In my opinion, porting the program (so you just take the source code and
recompile) is a myth started 20-30 years ago when world consisted of
UNIX systems. Well, world does not consist of UNIX systems anymore, but
there are 100s of different systems running in cell-phones, DVD players,
game consoles etc. And one of the very few programs which would work on
all these platforms is: "loop: goto loop;".

Another point is that real worls compilers almost never comply to the
standards. So even taking the code from one compiler to another and
recompiling is a myth unless we talk about some real simple one-evening
type of apps.

And the last but not least point is the justification of portability.
Say I write app in 500 hours using all possible compiler extensions.
Does it justify to write it perfectly portale and spend 1500 hours
instead ? In my eyes not, because I can probably write it from scratch
in another 500 hours or play with it a little and probably adjust it to
second platform or different compiler way faster.

To be honest ... to how many different plattforms and/or compilers are
you porting your programs in average ?

And please, before you start sending flames, please introduce the group
into your last project of porting the software between platforms. And
let it not be Win98 -> WinXp ...
Nov 14 '05 #1
Share this Question
Share on Google+
93 Replies


P: n/a
And so I am not only critisizing:

One of my recent mini-projects had to be developed on Win/PC and
recompile and work on PocketPC. ARM does not like to work with unaligned
words as much as Pentium and I used arena allocation for allocation
performance reasons. All it needed was to align arena allocated
structures to 32 bit ...

I guess anybody here can tell stories about endianity ...
Nov 14 '05 #2

P: n/a
roman ziak wrote:
And so I am not only critisizing:

One of my recent mini-projects had to be developed on Win/PC and
recompile and work on PocketPC. ARM does not like to work with unaligned
words as much as Pentium and I used arena allocation for allocation
performance reasons. All it needed was to align arena allocated
structures to 32 bit ...

I guess anybody here can tell stories about endianity ...


Netbsd. written in C, runs of over 50 architectures and has device drivers
independent of architecture.

C is a relatively low level lamnguage. If you don't understand architectures
& alignment then its your problem.

gtoomey
Nov 14 '05 #3

P: n/a
http://www.netbsd.org/People/developers.html

Did they forget to include you ?

It's easy to talk while others walk.
Nov 14 '05 #4

P: n/a

Oh, jeez. Sounds like you woke up on the wrong side of the bed
there, sparky.

Gregory's comments still stand.

You have an axe to grind with C? Fine. By the way, your comments
would also apply to C++.

Portability can not take into account all machine dependencies. One
of the likeable features of C is that it has low-level capabilities
even for a high level language. Can it bite you if you use without
being mindful of some of its inherent machine dependencies? Yep, it
sure can, and obviously that's the reason you're in a sour mood.

Realize C is just a tool, and you <can> use a tool the wrong way.
roman ziak <ne***@MYLASTNAME.com> wrote in news:M9KPd.885$QR.44870
@news20.bellglobal.com:

http://www.netbsd.org/People/developers.html

Did they forget to include you ?

It's easy to talk while others walk.


Nov 14 '05 #5

P: n/a
In article <JE****************@news20.bellglobal.com>,
roman ziak <ne***@MYLASTNAME.com> wrote:
:And the last but not least point is the justification of portability.
:Say I write app in 500 hours using all possible compiler extensions.
:Does it justify to write it perfectly portale and spend 1500 hours
:instead ? In my eyes not, because I can probably write it from scratch
:in another 500 hours or play with it a little and probably adjust it to
:second platform or different compiler way faster.

The programs we work [at my job] typically run into the
person-years range. If we were to re-write them, we would have
the advantage of knowing what -didn't- work [scientific programs
have a pretty high mutation rate when you are exploring to see what
-can- be done], but it would still take a long long time.
It doesn't take us 3 times as long to write it portably in the first
place.

:To be honest ... to how many different plattforms and/or compilers are
:you porting your programs in average ?

It depends greatly on the program. My particular job involves a lot
of systems administration work, wherein I'm writing programs for
my own needs rather than for someone else to use; such programs
only have to work for me, for one platform. I still write them
in portable code, unless I'm writing something that is system
specific (e.g., a program to change which CPU a different process
is locked to).

When I am working on the scientific programming part of my job, then
those programs are for more general use, and I take more special care
to ensure that the programs work on other platforms. Usually 3
platforms in such cases.
:And please, before you start sending flames, please introduce the group
:into your last project of porting the software between platforms. And
:let it not be Win98 -> WinXp ...

Latest.... hmmm, that would be a scientific program to determine
similarity between datasets ["similarity" in this case being a
fairly complex algorithm.] It had two major parts, written by
three completely different people. The first (larger) part had
been written by someone who probably shouldn't have been let near
a keyboard; it had been later modified by the second person, who
was a better programmer but who didn't try many large-scale changes
to the program. I cleaned up the code quite a bit and fixed numerous
bugs along the way. The second (smaller) part of the package was
not written to be portable (or even very maintainable), but it was
portable by the time I was finished with it. I couldn't change the
basic structure -too- much as it was still under active development.

When I was done, the program worked without changes on IRIX,
Solaris, and Linux, with the only conditional compilation being
a small section to determine the system serial number for license
locking purposes; that and one include file was slightly parameterized
to take into account that solaris put some of its types into
slightly different files.
Another team sat down to rewrite the code in "portable" Java.
It took them more than 6 person-years to get to the equivilent of
what I'd done in 8 months part-time, and their "Java is
defined as being portable" code wouldn't run on IRIX (relatively
soon into the project) or Solaris (as the project matured). By
the end of that 6 person years, they had decided to give up on Java
and go for pure C++ -- Java just couldn't give them the speed they
needed for accessing large multidimensional data sets in relatively
arbitrary manners.
When I'm writing (or re-writing) a program, I don't so much
set out to write it portably as I set out to write in what might be
called "generalizations". For example, the compute engine is
seperated from the display engine, and the interface between the
two is not through binary procedure calls but rather via an
ASCII command line interpreter. The display portion of the program
starts by sending the API version that it is expecting to talk to;
the compute engine then formats its outputs to conform to that
API version if it can, or tells the display portion the API ranges
it can handle otherwise. In this way, either section of the
code can be replaced as long as the API is conformed to, and there
are no issues about endian (unless the two parts negotiated
binary transfer, in which case the endian-ness of the data would
be negotiated too.)

As my code progresses [and keep in mind that the end-user requirements
can literally change within 5 minutes], I build more and more
abstraction layers, making the program more and more flexible -- making
it easier and easier to deal with the researcher changing his or her
mind, and making it easier and easier to port. I would be lying if I
said that all the abstraction layers were obvious to me when I started
the project: programming (especially with changing requirments) is
often a process of revelation of hidden order from the apparent
chaos.
--
Ceci, ce n'est pas une idée.
Nov 14 '05 #6

P: n/a
roman ziak wrote:
And so I am not only critisizing:

One of my recent mini-projects had to be developed on Win/PC and
recompile and work on PocketPC. ARM does not like to work with unaligned
words as much as Pentium and I used arena allocation for allocation
performance reasons. All it needed was to align arena allocated
structures to 32 bit ...

I guess anybody here can tell stories about endianity ...


Let us say that you are porting code from an 80386 processor to
an AM7TDMI in Big Endian configuration. (BTW, 80386 is Little
Endian).

Given the following common message structure:
struct Message
{
unsigned char command;
unsigned int message_length;
unsigned short checksum;
};
The compiler is allowed to add padding bytes between the fields.
This is from the language specification, regardless of the platform.

Knowing that padding bytes _may_ be added, one cannot
directly transfer this structure in a mirror copy. One
must access the fields directly.

For example, one cannot use fwrite() to serialize the
structure (i.e. send it out). The proper method is to
place each field sequentially into a buffer, then transmit
the buffer. This technique allows for no padding, regardless
of whether the compiler added padding bytes or not.

If you think portability is fun, try dealing with multiple
processors on the same platform that have different endian
or alignment restrictions.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

Nov 14 '05 #7

P: n/a
>On Sun, 13 Feb 2005 08:31:13 -0500, roman ziak <ne***@MYLASTNAME.com> wrote:

What I noticed is that your IP address is almost the same, or falls
within the same range of previous posters with this type of message
topic.

My best guess is, that the same person is trying to play to some of
the groups feelings and provoke reactions.

Time to add another anti-flame kill-filter to my nntpclient?

Chris.
Nov 14 '05 #8

P: n/a
roman ziak wrote:
I just read couple articles on this group and it keeps amazing me how the portability is used as strong argument for language cleanliness.

In my opinion, porting the program (so you just take the source code and recompile) is a myth started 20-30 years ago when world consisted of
UNIX systems. Well, world does not consist of UNIX systems anymore, but there are 100s of different systems running in cell-phones, DVD

players,

It's definitely possible to write both portable and non-portable user
code in C, and it's almost all about writing clean code.

On the other hand,
to do useful things, i.e. make a GUI program with mouse support,
you have to compromise the automatic portability

But you certainly can write appropriate code for the facilities
which depend on platform, and choose what code to use with #ifdefs.

Try doing this in assembly.

C is not the best at portability, according to the more modern
relative definition of portability...

Java for example is supposed to
provide automatic portability (What you lose in the process is
performance
and some basic capabilities: things you can do portably are limited by
the
high level SDK available, (and sometimes the high level SDK isn't good
enough)

For extreme examples
.... try writing a portable OS or tool in Java that dials out on the
modem or otherwise interacts directly with some piece of hardware
).

-Mysid

Nov 14 '05 #9

P: n/a
On 13 Feb 2005 14:13:25 -0800, "Mysidia" <my*****@gmail.com> wrote in
comp.lang.c:
roman ziak wrote:
I just read couple articles on this group and it keeps amazing me how
the portability is used as strong argument for language cleanliness.

In my opinion, porting the program (so you just take the source code

and
recompile) is a myth started 20-30 years ago when world consisted of
UNIX systems. Well, world does not consist of UNIX systems anymore,

but
there are 100s of different systems running in cell-phones, DVD

players,

It's definitely possible to write both portable and non-portable user
code in C, and it's almost all about writing clean code.

On the other hand,
to do useful things, i.e. make a GUI program with mouse support,
you have to compromise the automatic portability

But you certainly can write appropriate code for the facilities
which depend on platform, and choose what code to use with #ifdefs.

Try doing this in assembly.

C is not the best at portability, according to the more modern
relative definition of portability...

Java for example is supposed to
provide automatic portability (What you lose in the process is
performance
and some basic capabilities: things you can do portably are limited by
the
high level SDK available, (and sometimes the high level SDK isn't good
enough)


Except Java provides no portability at all to any platform that isn't
at least 32-bits with a multi-tasking GUI environment. C on the other
hand, does.
For extreme examples
... try writing a portable OS or tool in Java that dials out on the
modem or otherwise interacts directly with some piece of hardware
).

-Mysid


There is a C compiler, or more likely several or dozens, for virtually
every processor architecture in existence, from 8-bit microprocessors
and microcontrollers to 64-bit supercomputers.

No new processor or controller is ever introduced without some C
compiler being available these days. If the manufacturer does not
provide one free or sell it, they will subsidize at least one third
party compiler vendor to produce one.

You can't say that about Java, you can't say that about C++, in fact
you can't say that about any other language at all.

The core of C is the most portable language in existence, has been for
a long time, and will be for a long time to come.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #10

P: n/a
On Sun, 13 Feb 2005 08:31:13 -0500, roman ziak <ne***@MYLASTNAME.com>
wrote in comp.lang.c:
I just read couple articles on this group and it keeps amazing me how
the portability is used as strong argument for language cleanliness.
OK, here's my question:

"Are you a troll and an idiot, just a troll, or just an idiot?"
In my opinion, porting the program (so you just take the source code and
recompile) is a myth started 20-30 years ago when world consisted of
UNIX systems. Well, world does not consist of UNIX systems anymore, but
there are 100s of different systems running in cell-phones, DVD players,
game consoles etc. And one of the very few programs which would work on
all these platforms is: "loop: goto loop;".


Nonsense, you're talking about either platform-specific things like
GUIs and database access, or hardware specific things like low level
registers.

In computer programming, the core C language is the most portable in
existence. Period. There is no other language that exists on as many
architectures. Period.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #11

P: n/a
I can only agree that C is probably the first HL language of choice for
most newly introduced CPU platforms.

My point, however, was that there is certain expense on this
portability, unlike mentioned Java where portability is inherent since
plattform is same, regardless on the CPU.

If porting C programs was that easy, then hardware vendors would just
(with little effort) write their Windows drivers so they could be
recompiled under say Linux as the other popular PC platform. They don't
and that's even same CPU.

Why?

Because different platforms need different calls, different data
structures, ...

Portability is possible only when there is at least some common ground.
Standard C library is not enough, because computers communicate (non
standardized in CLIB), display stuff on screen (beside printf not
standardized in CLIB), have threads of execution (not standardized in
CLIB), control external devices etc.

Portability is not property of the language but its implementation.
Nov 14 '05 #12

P: n/a
"roman ziak" <ne***@MYLASTNAME.com> wrote in message
news:JE****************@news20.bellglobal.com...
I just read couple articles on this group and it keeps amazing me how
the portability is used as strong argument for language cleanliness.

In my opinion, porting the program (so you just take the source code
and recompile) is a myth started 20-30 years ago when world consisted
of UNIX systems. Well, world does not consist of UNIX systems
anymore, but there are 100s of different systems running in cell-
phones, DVD players, game consoles etc. And one of the very few
programs which would work on all these platforms is: "loop: goto
loop;".
A portable program should run on all of them.

I'll also note that systems today are much more consistent than they were
20-30 years ago. Byte sizes, memory models, integer representation, etc.
are identical on nearly every modern system -- arguably due to C's influence
on the industry.
Another point is that real worls compilers almost never comply to the
standards. So even taking the code from one compiler to another and
recompiling is a myth unless we talk about some real simple one-evening
type of apps.
Compilers do an excellent job of complying with the standard. What makes
programs unportable are all the extensions and libraries that are available
on some systems and not others. That is not C's fault.
And the last but not least point is the justification of portability.
Say I write app in 500 hours using all possible compiler extensions.
Does it justify to write it perfectly portale and spend 1500 hours
instead ? In my eyes not, because I can probably write it from scratch
in another 500 hours or play with it a little and probably adjust it to
second platform or different compiler way faster.
Writing an unportable program may take you 500 hours, but writing a portable
one would only take 600 hours or so. Trying to port existing code that
wasn't written with the intent of being portable may well take you another
1000 hours, but that's your fault for writing it unportably in the first
place.
To be honest ... to how many different plattforms and/or compilers are
you porting your programs in average ?

And please, before you start sending flames, please introduce the group
into your last project of porting the software between platforms. And
let it not be Win98 -> WinXp ...


A former employer of mine had a major application that ran just fine on
M68k, MIPS32, MIPS64, PPC32, PPC64, SPARC, IA32, and possibly others I'm
unaware of. It would use an MMU if available or fake one if not. It would
run on a microkernel, as an OS itself, or even as a user-mode Solaris
application. Certain files (in platform-specific directories) were
obviously unportable, but I'd estimate 95% of the code was portable.

In case you think that is a trivial example, the program was in the millions
of lines of source, with around 10,000 developers currently and a
development period of over a decade. Daily builds and test cycles against
all platforms were standard. Portability failures were unheard of because
the coders learned to write portable code. Several of those platforms were
added while I was there and it was almost trivial, requiring only
modifications or additions to files that were explicitly marked as
unportable.

( And no, it's not Windows or some UNIX variant... )

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

Nov 14 '05 #13

P: n/a
> Compilers do an excellent job of complying with the standard. What makes
programs unportable are all the extensions and libraries that are available
on some systems and not others.
Very true.
A former employer of mine had a major application that ran just fine on
M68k, MIPS32, MIPS64, PPC32, PPC64, SPARC, IA32, and possibly others I'm
unaware of. It would use an MMU if available or fake one if not. It would
run on a microkernel, as an OS itself, or even as a user-mode Solaris
application. Certain files (in platform-specific directories) were
obviously unportable, but I'd estimate 95% of the code was portable.

In case you think that is a trivial example, the program was in the millions
of lines of source, with around 10,000 developers currently and a
development period of over a decade. Daily builds and test cycles against
all platforms were standard. Portability failures were unheard of because
the coders learned to write portable code. Several of those platforms were
added while I was there and it was almost trivial, requiring only
modifications or additions to files that were explicitly marked as
unportable.


This is definitively impressive.

You say there was about 5% of the code, which was wrapping and
abstracting different platforms so the remaining 95% code could run
without change.

This portability is not the merit of the C language nor its standard
libraries, but good design of the proprietary runtime. Do you actually
think that if the language of choice of your employer was Pascal and
let's assume there would be a conforming Pascal compiler on each of
those plattforms, they would not succeed with the application ?
Nov 14 '05 #14

P: n/a
In article <Gq****************@news20.bellglobal.com>,
roman ziak <ne***@MYLASTNAME.com> wrote:
:I can only agree that C is probably the first HL language of choice for
:most newly introduced CPU platforms.

:My point, however, was that there is certain expense on this
:portability, unlike mentioned Java where portability is inherent since
:plattform is same, regardless on the CPU.

Java is not really portable -- it's API has changed too much over
time for that. There are several major components of Java, and you
need to match them closely.

Porting java itself to a new platform takes a fair bit of time and work.
Oh, and Java itself was originally written in C, according to Sun.
:If porting C programs was that easy, then hardware vendors would just
:(with little effort) write their Windows drivers so they could be
:recompiled under say Linux as the other popular PC platform. They don't
:and that's even same CPU.

You can't do that with Java either.
:Portability is possible only when there is at least some common ground.
:Standard C library is not enough, because computers communicate (non
:standardized in CLIB), display stuff on screen (beside printf not
:standardized in CLIB), have threads of execution (not standardized in
:CLIB), control external devices etc.

Several of those things are supposed standardized in Java... but
it's still not really portable.
--
I've been working on a kernel
All the livelong night.
I've been working on a kernel
And it still won't work quite right. -- J. Benson & J. Doll
Nov 14 '05 #15

P: n/a

roman ziak wrote:
I just read couple articles on this group and it keeps amazing me how the portability is used as strong argument for language cleanliness.


If C is not portable you had better inform my 100s of users...
Specially the Playstation folk who seem to think the software I wrote
partly in win32/x86, linux/x86_32 and linux/x86_64 will work on their
MIPS based system...

Might want to also talk to the MatrixSSL folk who use it in ARM
platforms and the BitMover folk who use it in about 12 other
platforms...

:-)

Tom

Nov 14 '05 #16

P: n/a

roman ziak wrote:
I can only agree that C is probably the first HL language of choice for most newly introduced CPU platforms.

My point, however, was that there is certain expense on this
portability, unlike mentioned Java where portability is inherent since plattform is same, regardless on the CPU.

If porting C programs was that easy, then hardware vendors would just (with little effort) write their Windows drivers so they could be
recompiled under say Linux as the other popular PC platform. They don't and that's even same CPU.

Why?


Cuz maybe the WinNT and Linux Kernel don't work the same way? That has
NOTHING todo with the C language...

Now I know for a fact you're just a troll.

BTW Things like GUI and dB access ARE fairly portable. It's called
Motif and MySQL. Heck libs like GTK+ and QT are even fairly portable
[even ported to windows].

So I really think you're [all of]

a) a troll
b) ignorant
c) an ignorant troll

Tom

Nov 14 '05 #17

P: n/a
"roman ziak" <ne***@MYLASTNAME.com> wrote in message
news:JE****************@news20.bellglobal.com...

Another point is that real worls compilers almost never comply to the
standards. So even taking the code from one compiler to another and
recompiling is a myth unless we talk about some real simple one-evening type of apps.
World. We call it the "real world".

And the last but not least point is the justification of portability.
Say I write app in 500 hours using all possible compiler extensions.
Does it justify to write it perfectly portale and spend 1500 hours
instead ? In my eyes not, because I can probably write it from scratch
in another 500 hours or play with it a little and probably adjust it to second platform or different compiler way faster.
Portable. We call it portable, not portale.

To be honest ... to how many different plattforms and/or compilers are
you porting your programs in average ?
Platforms. And we port _to_ them "on average" not "in average".

And please, before you start sending flames, please introduce the group into your last project of porting the software between platforms. And
let it not be Win98 -> WinXp ...


I ported my Windows game to the Palm OS. It was a total re-write. I'm
thinking about a cellular phone version, but there is no pointer tool
for a cell phone...

--
Mabden
Nov 14 '05 #18

P: n/a
jjf

roman ziak wrote:
http://www.netbsd.org/People/developers.html

Did they forget to include you ?

It's easy to talk while others walk.


What does the presence or otherwise of Gregory's name in the
NetBSD developer list have to do with his proof that you are
talking nonsense?

Nov 14 '05 #19

P: n/a

"roman ziak" <ne***@MYLASTNAME.com> wrote in message
news:aL****************@news20.bellglobal.com...
Compilers do an excellent job of complying with the standard. What makes programs unportable are all the extensions and libraries that are available on some systems and not others.
Very true.
A former employer of mine had a major application that ran just fine on
M68k, MIPS32, MIPS64, PPC32, PPC64, SPARC, IA32, and possibly others I'm
unaware of. It would use an MMU if available or fake one if not. It would run on a microkernel, as an OS itself, or even as a user-mode Solaris
application. Certain files (in platform-specific directories) were
obviously unportable, but I'd estimate 95% of the code was portable.

In case you think that is a trivial example, the program was in the millions of lines of source, with around 10,000 developers currently and a
development period of over a decade. Daily builds and test cycles against all platforms were standard. Portability failures were unheard of because the coders learned to write portable code. Several of those platforms were added while I was there and it was almost trivial, requiring only
modifications or additions to files that were explicitly marked as
unportable.


This is definitively impressive.

You say there was about 5% of the code, which was wrapping and
abstracting different platforms so the remaining 95% code could run
without change.

This portability is not the merit of the C language nor its standard
libraries, but good design of the proprietary runtime.


Gcc, to name but one, is not proprietary. But you are right. Portability
starts
with good design. Separating model from representation, for instance, or
encapsulation,
tight coherence and loose coupling....
Do you actually think that if the language of choice of your employer was Pascal and let's assume there would be a conforming Pascal compiler on each of
those plattforms, they would not succeed with the application ?


Actually, no.

If they would use a conforming Pascal compiler, you can forget about
anything dealing with actual hardware, building *large* systems, using
external libraries, etc. The program you *can* write will be fairly
portable, but quite limited. Besides, two different implementations may have
different ideas on what the maximum value for an integer is, what precision
floating points have, etc. All those things so neatly coped with in the
various standard C headers.

Assuming you have some non-conforming implementation (like Turbo-Pascal),
you'd be in worse trouble, since you are limited to *that* specific compiler
and the platforms it supports.

Conforming Pascal is a great language for programming-classes, but not for
actual software development.
Nov 14 '05 #20

P: n/a
Jack Klein wrote:
On 13 Feb 2005 14:13:25 -0800, "Mysidia" <my*****@gmail.com> wrote:
C is not the best at portability, according to the more
modern relative definition of portability...
You mean where *semantics* get added to the definition?
Java for example is supposed to provide automatic portability
(What you lose in the process is performance and some basic
capabilities: things you can do portably are limited by the
high level SDK available, (and sometimes the high level SDK
isn't good enough)
Except Java provides no portability at all to any platform that
isn't at least 32-bits with a multi-tasking GUI environment.


What are you talking about? A VM can emulate multitasking -- an
underlying OS which does so is irrelevant (in fact, I would be curious
to know, if in fact, the Java spec *REQUIRES* the multitasking to be
emulated, so that race conditions are limited to VM instruction
granularity.) Interfacing with GUI environments has to be done with
some kind of native method rig up, and again is not a gating factor in
the ability to run Java. And 32 bits -- are you smoking something? You
just have to present the interface, there only requirements for the
underlying machine is that it can compute something.

For example, there was a port of Java to DOS (called Kaffe, I believe.)
You are confusing what is exposed with what is required by the
platform.
[...] C on the other hand, does.
C requires the existence of files/stdio, and a system timer. Voting
machines can arguably be considered more secure if they do *NOT*
contain any system timer (consider software which waits for the
election date, or well past the start of a real election before
enacting a "flaw" -- a little hard to do without a timer).
There is a C compiler, or more likely several or dozens,
for virtually every processor architecture in existence,
from 8-bit microprocessors and microcontrollers to 64-bit
supercomputers.
Yes, but I think the OP's point is that no pair of any such compilers
accepts the same set of source inputs and does not generate
semantically compatible output for the intersection of code that is
common.
No new processor or controller is ever introduced without
some C compiler being available these days.
I am aware of at least one smart card that was -- they implemented a
picojava instruction set for it. Think about the complexities involved
in architecture design and bring up -- there can't possibly be any
since they have most of it specced out for them already.
The core of C is the most portable language in existence, has
been for a long time, and will be for a long time to come.


You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable. I think the only two languages I know of which are
*less* portable than C are assembly and Basic.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 14 '05 #21

P: n/a
George Wicks wrote:

Oh, jeez. Sounds like you woke up on the wrong side of the bed
there, sparky.

Gregory's comments still stand.


The OP is a moron.

gtoomey
Nov 14 '05 #22

P: n/a
Gregory Toomey <no****@bigpond.com> wrote in news:37bpn8F5am5ieU1
@individual.net:

Yes, I see what you mean..
George Wicks wrote:

Oh, jeez. Sounds like you woke up on the wrong side of the bed
there, sparky.

Gregory's comments still stand.


The OP is a moron.

gtoomey


Nov 14 '05 #23

P: n/a
> BTW Things like GUI and dB access ARE fairly portable. It's called
Motif and MySQL. Heck libs like GTK+ and QT are even fairly portable
[even ported to windows].


Since when Motif, MySQL, GTK, QT became part of C ?
Nov 14 '05 #24

P: n/a
"roman ziak" <ne***@MYLASTNAME.com> wrote in message
news:aL****************@news20.bellglobal.com...
This is definitively impressive.

You say there was about 5% of the code, which was wrapping and
abstracting different platforms so the remaining 95% code could run
without change.
I'm not sure I'd put it that way. Very little of the code cared at all what
platform it ran on; nothing is abstracted if you're simply ignoring the
details.

5% of the code couldn't ignore platform-specific details because it
consisted of device drivers and such. Since it was all custom hardware,
except for the memory and CPU, we'd have had to write that all from scratch
anyways.
This portability is not the merit of the C language nor its standard
libraries, but good design of the proprietary runtime.
What runtime? In most cases (actually, in all cases for customer-shipped
code) the software ran directly on the hardware -- no runtime, no OS, no VM,
etc. except what we provided ourselves.

~95% of the code was cleanly portable across widely different platforms;
that means that _well-written_ C code is portable.
Do you actually
think that if the language of choice of your employer was Pascal and
let's assume there would be a conforming Pascal compiler on each of
those plattforms, they would not succeed with the application ?


It might be possible, though I'm not convinced, to write the portable 95% of
the code in Pascal, Java, COBOL, Perl, or a variety of other languages.
However, that means finding suitable compilers and possibly VMs for each of
the platforms, which are clearly not as easily available as C compilers and
rarely anywhere near as fast at runtime. C is at least as portable as other
languages, and is arguably more portable.

Also important was that the nonportable ~5% could only be written in C or
ASM -- no other languages provide access to unportable constructions _even
if that's what's explicitly desired_. Try writing device drivers, VMMs, or
schedulers in Java or Pascal -- unportable extensions must be written in C
and linked in, and then your overall program becomes just as "unportable" as
a C version would be.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

Nov 14 '05 #25

P: n/a
we******@gmail.com <we******@gmail.com> wrote:
You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable. I think the only two languages I know of which are
*less* portable than C are assembly and Basic.


Perhaps I need my coffee, but *how* is Perl and Python _FAR_ more
portable than C?

Other than endian-issues, standard c seems just as portable as
either python or perl. Assuming that endian issues are avoided
or worked around, I'm assuming its _as_ portable.

In practice, it would appear that far more architectures have a
c compiler available than a perl interpreter. Since perl is
written in c, the number of architectures that support perl
has to be less than or equal to the number of architectures
that support c.

Non-portable perl is rather easy to create: Go on CPAN and grab
a nifty module. Oopsie, its not available on win32. There goes
portability!

Just my $.02,

Jesse Meyer

--
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
Nov 14 '05 #26

P: n/a
In article <11*********************@l41g2000cwc.googlegroups. com>,
<we******@gmail.com> wrote:
:You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
:more portable. I think the only two languages I know of which are
:*less* portable than C are assembly and Basic.

Perl... Every time I load in a new perl release, I have to
spend at least a day in hacking it to make it functional on SGI IRIX.
Which often comes down to a matter of choising which test errors
to accept and force installation despite the failure.

Some of the fundamental perl modules in CPAN, including some of
the basic ones like POD to MAN conversion, are broken. Often the
only way to get them to work is to either recompile *all* of Perl
via gcc, or to hack the system header files. But these days if
I convert to gcc, then the way that gcc likes to lie about ANSI C
conformance result in conflict with SGI's namespace macros, and
if I use SGI's C compiler (which is usually quote strict on
error checking), then h2ph never gets right the conversion of
the wait structure [which is a typecast]...

All in all, -every- meaningful update I do to load in the
latest Perl or latest releases of the CPAN modules means that I
will have to spend about a full day loading, compile, debugging,
hacking. And I have to do the same thing all over again when
I go to update on Mac OSX.

A lot of the time it feels like I am spending more time on
porting and fixing perl than I am on actually -using- perl.
--
*We* are now the times. -- Wim Wenders (WoD)
Nov 14 '05 #27

P: n/a
we******@gmail.com wrote:
Jack Klein wrote:
The core of C is the most portable language in existence, has
been for a long time, and will be for a long time to come.


You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable.


*Snigger* _Perl_? Portable? Please, tell me what you've been drinking, I
want to live in that happy world, too!

FWIW, I've got a pretty good, complete C compiler for MS-DOS. Last time
I saw the Perl interpreter for MS-DOS, almost half of its documentation
consisted of pages stating "This function has not been ported to DOS".

Richard
Nov 14 '05 #28

P: n/a
On Sun, 13 Feb 2005 08:31:13 -0500, roman ziak <ne***@MYLASTNAME.com>
wrote:

In my opinion,
You are entitled to your beliefs; only an expert is entitled to an
opinion.

And please, before you start sending flames, please introduce the group
into your last project of porting the software between platforms. And
let it not be Win98 -> WinXp ...


Flames sent - you are clearly speaking from ignorance. Nothing wrong with
ignorance, except when you're as proud of it as you seem to be.

We developed an application over several years. It started under DOS, got
moved to pSOS on an ARM, got moved to linux on an x86, and is being moved
to another real-time OS. From DOS to pSOS the OS interface was changed -
it hasn't been changed since. New features have been added and bugs
fixed, but the application code is identical across four different
operating systems and seven hardware platforms. We still actively support
all of them except the COS version, and fixes and features are retro
fitted so older customers can have the latest.

If your example of 500 vs. 1500 hours is accurate, then you don't really
know how to program in C. I find it takes very little more time to write
pretty-much portable code than compiler/environment specific code - and
usually less time. I go back and forth between compilers and platforms -
it's rarely worth learning each compiler's extensions.

--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list
Nov 14 '05 #29

P: n/a
Jesse Meyer wrote:
we******@gmail.com <we******@gmail.com> wrote:
You misspelled *least*. Lua, Python and Perl, for example, are
*FAR* more portable. I think the only two languages I know of
which are *less* portable than C are assembly and Basic.
Perhaps I need my coffee, but *how* is Perl and Python _FAR_ more
portable than C?


Code you write in Python/Perl that doesn't use use obvious native
functionality behaves identically on any platform that implements them?
Other than endian-issues, standard c seems just as portable as
either python or perl.
You can't even use an int and be sure to be portable.
[...] Assuming that endian issues are avoided or worked around, I'm
assuming its _as_ portable.
?!?! Endianness anonimity is the *least* of C's problems. Tell me, If
you cast a long to a double do you lose accuracy? If you right shift a
signed integer, what do you expect to happen?
In practice, it would appear that far more architectures have a
c compiler available than a perl interpreter.
Ok. Availability != portability. This isn't the first time I've had
to point this out in this newsgroup. Portability, means you simply
take your code and you can move it to completely different kind of
platform (with an avaiable compiler/interpretor for the language).
Perl, Python and Lua are interpreters, so they are *source* portable.
Java is a compiler that is *binary* portable. C ... well its just not
portable at all. C is *available* -- and it is even possible to write
source programs that are portable to some subset of platforms which
have C compilers.

I mean machine language is at least as "portable" as C if you are going
to claim that platform availability is what portability means.
[...] Since perl is written in c, the number of architectures that
support perl has to be less than or equal to the number of
architectures that support c.
Which has nothing to do with portability ...
Non-portable perl is rather easy to create: Go on CPAN and grab
a nifty module. Oopsie, its not available on win32. There goes
portability!


Ok, but those are native extensions. And I am sure that they are
clearly marked as such.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 14 '05 #30

P: n/a
On Sun, 13 Feb 2005 08:31:13 -0500, roman ziak <ne***@MYLASTNAME.com>
wrote:

And the last but not least point is the justification of portability.
Say I write app in 500 hours using all possible compiler extensions.
Does it justify to write it perfectly portale and spend 1500 hours
instead ?


I suggest that you invest some of those hours in learning good program
design principles, and how to write portable code without investing
extra time.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #31

P: n/a
In article <11*********************@g14g2000cwa.googlegroups. com>,
<we******@gmail.com> wrote:
:Jesse Meyer wrote:
:> Perhaps I need my coffee, but *how* is Perl and Python _FAR_ more
:> portable than C?

:Code you write in Python/Perl that doesn't use use obvious native
:functionality behaves identically on any platform that implements them?

Read the perlop man pages. It has a number of instances where it
says that various parts are implimented in terms of C types. For
example, see the descriptions of ~ and <<

:You can't even use an int and be sure to be portable.

Nor can you in perl.
:?!?! Endianness anonimity is the *least* of C's problems. Tell me, If
:you cast a long to a double do you lose accuracy? If you right shift a
:signed integer, what do you expect to happen?

And these things are well defined in perl?

:Perl, Python and Lua are interpreters, so they are *source* portable.

I can't speak about Python or Lua, but Perl is *not* source portable.
:> Non-portable perl is rather easy to create: Go on CPAN and grab
:> a nifty module. Oopsie, its not available on win32. There goes
:> portability!

:Ok, but those are native extensions. And I am sure that they are
:clearly marked as such.

No, there are quite a few CPAN modules which were written to
be portable, but which really aren't. They can't even get right
the pure perl modules that convert embedded comments into manual
pages.
--
I predict that you will not trust this prediction.
Nov 14 '05 #32

P: n/a
<we******@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...
Jesse Meyer wrote:
we******@gmail.com <we******@gmail.com> wrote:
You misspelled *least*. Lua, Python and Perl, for example, are
*FAR* more portable. I think the only two languages I know of
which are *less* portable than C are assembly and Basic.


Perhaps I need my coffee, but *how* is Perl and Python _FAR_ more
portable than C?


Code you write in Python/Perl that doesn't use use obvious native
functionality behaves identically on any platform that implements them?


Code you write in C that doesn't rely on undefined or implementation-defined
behavior behaves identically on any conforming system.

Of course, Standard C has a far smaller space of defined behavior as well as
a much smaller standard library, but it also runs on significantly more
platforms than Perl or Python will ever run on.

As you note, availability isn't portability, but what do I care that Perl
defines a particular behavior that C doesn't when Perl doesn't run on the
dozen systems I care about? You can't port Perl when there's no runtime
available, whereas C source at least has a _chance_ of porting, depending on
how well it was written.
Other than endian-issues, standard c seems just as portable as
either python or perl.


You can't even use an int and be sure to be portable.


That depends on whether you stick to the constraints that are guaranteed to
be portable.
Non-portable perl is rather easy to create: Go on CPAN and grab
a nifty module. Oopsie, its not available on win32. There goes
portability!


Ok, but those are native extensions. And I am sure that they are
clearly marked as such.


There are many modules written purely in Perl that make no native calls but
still fail to be portable even to various POSIX systems.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

Nov 14 '05 #33

P: n/a
On Sun, 13 Feb 2005 20:55:31 -0600, in comp.lang.c , roman ziak
<ne***@MYLASTNAME.com> wrote:
My point, however, was that there is certain expense on this
portability, unlike mentioned Java where portability is inherent since
plattform is same, regardless on the CPU.
Er, Java isn't portable. You have to write a nonportable JVM for every
platform first. This severely restricts portability to platforms that
support whatever is required from a JVM.
Portability is not property of the language but its implementation.


Portability is a property of the language /and/ its implementation.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 14 '05 #34

P: n/a
On Mon, 14 Feb 2005 23:19:06 +0000, Mark McIntyre
<ma**********@spamcop.net> wrote:
On Sun, 13 Feb 2005 20:55:31 -0600, in comp.lang.c , roman ziak
<ne***@MYLASTNAME.com> wrote:
My point, however, was that there is certain expense on this
portability, unlike mentioned Java where portability is inherent since
plattform is same, regardless on the CPU.
Er, Java isn't portable. You have to write a nonportable JVM for every
platform first. This severely restricts portability to platforms that
support whatever is required from a JVM.


Yes. Even J2ME, the stripped-down version for embedded systems, is not
implemented on many platforms. Sun claims "millions of devices", but
that could be only one chip ;-)
Portability is not property of the language but its implementation.


Portability is a property of the language /and/ its implementation.


--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #35

P: n/a
On 14 Feb 2005 04:47:12 -0800, we******@gmail.com wrote in
comp.lang.c:
Jack Klein wrote:
On 13 Feb 2005 14:13:25 -0800, "Mysidia" <my*****@gmail.com> wrote:
C is not the best at portability, according to the more
modern relative definition of portability...
You mean where *semantics* get added to the definition?
Java for example is supposed to provide automatic portability
(What you lose in the process is performance and some basic
capabilities: things you can do portably are limited by the
high level SDK available, (and sometimes the high level SDK
isn't good enough)
Except Java provides no portability at all to any platform that
isn't at least 32-bits with a multi-tasking GUI environment.


What are you talking about? A VM can emulate multitasking -- an
underlying OS which does so is irrelevant (in fact, I would be curious
to know, if in fact, the Java spec *REQUIRES* the multitasking to be
emulated, so that race conditions are limited to VM instruction
granularity.) Interfacing with GUI environments has to be done with
some kind of native method rig up, and again is not a gating factor in
the ability to run Java. And 32 bits -- are you smoking something? You
just have to present the interface, there only requirements for the
underlying machine is that it can compute something.

For example, there was a port of Java to DOS (called Kaffe, I believe.)
You are confusing what is exposed with what is required by the
platform.


Is there a port of Java to PIC, 8051, AVR, ST7, or any DSP in the
world? There are C compilers for all of them, C++ for some. No Java,
Perl, Lisp, Visual Basic, C#, or any other flavor of the month.
[...] C on the other hand, does.


C requires the existence of files/stdio, and a system timer. Voting


Whatever gave you that silly, and totally wrong idea? C specifically
defines two types of implementations. A hosted environment does
indeed require stdio, a free-standing environment does not. No
implementation of C requires a system timer. There is no such
requirement in the language standard at all.
machines can arguably be considered more secure if they do *NOT*
contain any system timer (consider software which waits for the
election date, or well past the start of a real election before
enacting a "flaw" -- a little hard to do without a timer).
But your point is moot, because C does not require any sort of timer,
not in any environment. Not under any circumstances, even in a
strictly conforming hosted environment. The time() function merely
returns (time_t)-1. Period, end of story.

Heck, in 1999 I had to produce and sign documents for a variety of
systems affirming that they could not possibly have a Y2K problem
because they had no time-of-day hardware, and neither used outside
world time nor even had a method in their communications protocol of
receiving one.
There is a C compiler, or more likely several or dozens,
for virtually every processor architecture in existence,
from 8-bit microprocessors and microcontrollers to 64-bit
supercomputers.


Yes, but I think the OP's point is that no pair of any such compilers
accepts the same set of source inputs and does not generate
semantically compatible output for the intersection of code that is
common.
No new processor or controller is ever introduced without
some C compiler being available these days.


I am aware of at least one smart card that was -- they implemented a
picojava instruction set for it. Think about the complexities involved
in architecture design and bring up -- there can't possibly be any
since they have most of it specced out for them already.
The core of C is the most portable language in existence, has
been for a long time, and will be for a long time to come.


You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable. I think the only two languages I know of which are
*less* portable than C are assembly and Basic.


You seem to think, even as computers of all sizes are being introduced
into almost everything, that the entire world is one problem domain.

The most recent estimates I have heard are that there are
approximately 1,000,000,000 CPUs/processors/controllers being
manufactured and used per year. Approximately 150,000,000, or about
15% of them, are the 32-bit and 64-bit processors used as the main CPU
in laptop/desk top/workstation/server applications, an extremely
narrow range of applications.

The other 85% cover a much wider range than that.

Take a good look at the computer you are using to view Google and read
and post messages. It has one CPU, Pentium or equivalent or perhaps a
PowerPC. How many other programmed execution units does it have?

One in the keyboard, one in the mouse, one in the hard disk drive, one
in the CD/DVD drive. One or more in the printer, another in the
router if you use one. Oh, don't forget one in the monitor.

If you have a common home desk top setup, your router could well have
an ARM in it, and might be running under a version of Linux, perhaps
with real time extensions. So most or all of the languages you
mention above are available for that platform, as well as for the main
computer's CPU.

As for the others, if they have anything available at all besides an
assembler available, it is a C compiler.
---
A proper signature line consists of "-- ", that is two dash characters
and a space. As specified by relevant RFCs. Most competent
newsreaders handle trimming automatically. Incorrect signature
delimiters are a sign of a social engineering, not a technical,
problem.
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/


--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #36

P: n/a
Mark McIntyre wrote:

On Sun, 13 Feb 2005 20:55:31 -0600, in comp.lang.c , roman ziak
<ne***@MYLASTNAME.com> wrote:
My point, however, was that there is certain expense on this
portability, unlike mentioned Java where portability is inherent since
plattform is same, regardless on the CPU.
Er, Java isn't portable. You have to write a nonportable JVM for every
platform first.


Just a nit... By the same reasoning, C isn't portable either, because
you have to write a nonportable C compiler for every platform first.
This severely restricts portability to platforms that
support whatever is required from a JVM.
....or whatever is required from a C compiler.
Portability is not property of the language but its implementation.


Portability is a property of the language /and/ its implementation.


Portability is a myth. But it is with C that the myth most closely
approaches reality.
Nov 14 '05 #37

P: n/a

roman ziak wrote:
BTW Things like GUI and dB access ARE fairly portable. It's called
Motif and MySQL. Heck libs like GTK+ and QT are even fairly portable [even ported to windows].


Since when Motif, MySQL, GTK, QT became part of C ?


Um, you do realize that the Java language doesn't include Swing and the
7000 other classes right? This argument is really retarded though so
this is what I would expect...

You're saying Java is better because it *comes with* gui and such...

Well by that token by Gentoo distro *came with* GTK+, Motif and X11.
So I don't see why I can't code guis with C with ease. Also most *nix
like platforms come with Motif and X11 [and likely GTK+]...

So what exactly is your point?

Tom

Nov 14 '05 #38

P: n/a

roman ziak wrote:
In case you think that is a trivial example, the program was in the millions of lines of source, with around 10,000 developers currently and a
development period of over a decade. Daily builds and test cycles against all platforms were standard. Portability failures were unheard of because the coders learned to write portable code. Several of those platforms were added while I was there and it was almost trivial, requiring only
modifications or additions to files that were explicitly marked as
unportable.


This is definitively impressive.

You say there was about 5% of the code, which was wrapping and
abstracting different platforms so the remaining 95% code could run
without change.

This portability is not the merit of the C language nor its standard
libraries, but good design of the proprietary runtime. Do you

actually

....

Real software developers learn to factor their code into functional
components. For instance in Mozilla the part that decodes HTML and the
part that actually displays something should be completely separated.

That way when you port Mozilla you port the GUI code and not the HTML
engine.

This is no different for any other project... In most apps the UI can
be a relatively insignificant part of the project development....

Of course you'd know this because of your vast amounts of experience
you required to pass judgement on how bad C is...

Tom

Nov 14 '05 #39

P: n/a
Jack Klein wrote:
we******@gmail.com wrote in comp.lang.c:
For example, there was a port of Java to DOS (called Kaffe, I believe.)
You are confusing what is exposed with what is required by the
platform.
Is there a port of Java to PIC, 8051, AVR, ST7, or any DSP in the
world? There are C compilers for all of them, C++ for some. No

Java, Perl, Lisp, Visual Basic, C#, or any other flavor of the month.
Portability != Availability.
The core of C is the most portable language in existence, has
been for a long time, and will be for a long time to come.


You misspelled *least*. Lua, Python and Perl, for example, are *FAR* more portable. I think the only two languages I know of which are
*less* portable than C are assembly and Basic.


You seem to think, even as computers of all sizes are being

introduced into almost everything, that the entire world is one problem domain.

The most recent estimates I have heard are that there are
approximately 1,000,000,000 CPUs/processors/controllers being
manufactured and used per year.
This has nothing to do with portability.
[...] Approximately 150,000,000, or about
15% of them, are the 32-bit and 64-bit processors used as the main CPU in laptop/desk top/workstation/server applications, an extremely
narrow range of applications.
This has nothing to do with portability.
The other 85% cover a much wider range than that.
This has nothing to do with portability.
Take a good look at the computer you are using to view Google and read and post messages. It has one CPU, Pentium or equivalent or perhaps a PowerPC. How many other programmed execution units does it have?
This has nothing to do with portability.
As for the others, if they have anything available at all besides an
assembler available, it is a C compiler.


This has nothing to do with portability. By your incorrect definition
of portability, assembly is far and away the most portable language.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 14 '05 #40

P: n/a
we******@gmail.com <we******@gmail.com> wrote:
---
Paul Hsieh
http://www.pobox.com/~qed/


I visited your webpage.

One the third example that you gave for optimizations (if statements
within for loops), did you ever _benchmark_ the code you complained
about?

I wrote up a quick example in the same style, and over a million
loops, the 'optimized' example was less than .02 ms seconds faster
per loop on a 1Ghz Thunderbird.

Obviously, this is all dependent on what they were actually doing,
the compiler, the OS, the machine in question, and the phase of the
moon, but perhaps they profiled their performance critical code
and came up with similar numbers.

One thing is (probably) certain: The original way the code was written
is easier to read and change.

As Knuth said: Premature optimization is the root of all evil.
Until you profile the code in question, you don't know where to
focus your attention.

--
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
Nov 14 '05 #41

P: n/a
jj*@bcs.org.uk wrote:
roman ziak wrote:
http://www.netbsd.org/People/developers.html

Did they forget to include you ?

It's easy to talk while others walk.

What does the presence or otherwise of Gregory's name in the
NetBSD developer list have to do with his proof that you are
talking nonsense?


My question was how many different plattforms are you porting your
programs on average.

To be honest, I got carried away, because I offered my mistake together
with fix to start discussion about portability and yet he offered and
noncostructive insult.
Nov 14 '05 #42

P: n/a
Jesse Meyer wrote:
we******@gmail.com <we******@gmail.com> wrote:
---
Paul Hsieh
http://www.pobox.com/~qed/
I visited your webpage.

One the third example that you gave for optimizations (if
statements within for loops), did you ever _benchmark_ the
code you complained about?


Yeah -- its called branch mis-predictions. Its a question of how many
of them you want to pay for. Its actually just a very simple math
problem.
I wrote up a quick example in the same style, and over a
million loops, the 'optimized' example was less than .02
ms seconds faster per loop on a 1Ghz Thunderbird.
Well I don't know what kind of example you wrote. I assume you didn't
play much with the predicability of the branches? You'll notice this
optimization (which I wrote about prior to the existence of the Athlon
CPU) didn't make the code go slower.
Obviously, this is all dependent on what they were actually
doing, the compiler, the OS, the machine in question, and the
phase of the moon, but perhaps they profiled their performance
critical code and came up with similar numbers.
It also depends on some degree of understanding by the programmer. Its
like math -- once you understand how and why it works it doesn't become
something which you form an opinion about. It just is what it is.
One thing is (probably) certain: The original way the code
was written is easier to read and change.
Yeah ok, so did you notice that the title of the web page was not
"Guidelines for making maintainable readable code"? You apply
optimization in just enough doses to deal with your bottlenecks. I
would have thought everyone knew this already.
As Knuth said: Premature optimization is the root of all evil.
Yes ok, well Knuth doesn't write 3D video games. And he cleverly put
the word "premature" in there. That's like saying "eating too much
food is bad for you" -- that doesn't mean food is bad for you.
Until you profile the code in question, you don't know
where to focus your attention.


You understand that there is a non-trivial probability that you can
trace that bit of wisdom from wherever you heard it right back to me
right?

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 14 '05 #43

P: n/a
to********@gmail.com wrote:
Real software developers learn to factor their code into functional
components. For instance in Mozilla the part that decodes HTML and the
part that actually displays something should be completely separated.

That way when you port Mozilla you port the GUI code and not the HTML
engine.

This is no different for any other project... In most apps the UI can
be a relatively insignificant part of the project development....
Oh please ... "real software developers" ?

Interestingly enough, the Firefox (which uses Gecko as Mozilla), has a
subdirectory "chrome", which is heart of the app and contains plethora
of JavaScript files in them.

Most of the apps mentioned in this thread were going through their
evolution and needed to be changed at least when were ported to the
second plattform.

Only narrow scale of algorithms are part of the language and its
libraries. It is relatively easy to implement conforming C compiler than
conforming C++ compiler or VM based language with definitions for
broader scale of algorithms.
Of course you'd know this because of your vast amounts of experience
you required to pass judgement on how bad C is...


And yet, I did not say in this thread or anywhere else, that C is bad or
that Java (Pascal, Basic, C++, whatever) is better as
Nov 14 '05 #44

P: n/a
On Sun, 13 Feb 2005 08:46:55 -0500, roman ziak <ne***@MYLASTNAME.com>
wrote:
And so I am not only critisizing:

One of my recent mini-projects had to be developed on Win/PC and
recompile and work on PocketPC. ARM does not like to work with unaligned
words as much as Pentium and I used arena allocation for allocation
performance reasons. All it needed was to align arena allocated
structures to 32 bit ...
Pentiums don't like unaligned words, either. They don't give you a bus
error, they just slow to a crawl. Don't use them.

I would guess that much of your problem with porting code is improper
usage of the language. Why was the data misaligned in the first place?
Did the compiler warn you, or did you silence it with casts?
I guess anybody here can tell stories about endianity ...


ARM will work either big or little endian.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #45

P: n/a
> Real software developers learn to factor their code into functional
components. For instance in Mozilla the part that decodes HTML and the
part that actually displays something should be completely separated.
This should hold true! Unfortunately, it's not always that way.
But how many "real software developers" out there, anyway?
Oh wait. There are even some people who strongly believe that
this kind of "modular" programming can only be done with an
OO language.

Maybe it's time we raised the bar in software engineering education...
That way when you port Mozilla you port the GUI code and not the HTML
engine.
Yup! Or at least only the platform-dependent stuff: that can be a
lot of other things beside GUI. But any kind of decent programming
practice should make this at least possible without having to rewrite
the whole thing from scratch.
This is no different for any other project... In most apps the UI can
be a relatively insignificant part of the project development....


That, that depends on the project. Some software pieces are mostly
UI stuff, and nothing of real interest behind that (maybe what's
underneath would be ported in a couple hours, lol). I'm not giving
any names, but...

Actually, I really wish the UI would be an insignificant part of most
software projects.
Nov 14 '05 #46

P: n/a
we******@gmail.com <we******@gmail.com> wrote:
Jesse Meyer wrote:
we******@gmail.com <we******@gmail.com> wrote:
> ---
> Paul Hsieh
> http://www.pobox.com/~qed/


I visited your webpage.

One the third example that you gave for optimizations (if
statements within for loops), did you ever _benchmark_ the
code you complained about?


Yeah -- its called branch mis-predictions. Its a question of how many
of them you want to pay for. Its actually just a very simple math
problem.


You don't have a benchmark: That's a theory. The theory is that
your compiler is converting your code into inefficient instructions,
and that set of code is where your program is spending a large
amount of time in that segment of code.

Now, I don't know what processor you are running on, but with
the environment you are speaking of (Redmond/games), it seems
that it would probably be from the x86 line. While processor
architecture isn't one of my strengths, I believe that even the
early pentiums had branch prediction along the lines of "assume
this conditional will evalulate the same way it did previously",
in which case, we won't see branch mis-prediction, but only the
cost of the conditional evalulation.
I wrote up a quick example in the same style, and over a
million loops, the 'optimized' example was less than .02
ms seconds faster per loop on a 1Ghz Thunderbird.


Well I don't know what kind of example you wrote. I assume you didn't
play much with the predicability of the branches? You'll notice this
optimization (which I wrote about prior to the existence of the Athlon
CPU) didn't make the code go slower.


Putting a spoiler on a chevy metro won't make the car go slower:
It won't make it go measurably faster though.
Obviously, this is all dependent on what they were actually
doing, the compiler, the OS, the machine in question, and the
phase of the moon, but perhaps they profiled their performance
critical code and came up with similar numbers.


It also depends on some degree of understanding by the programmer. Its
like math -- once you understand how and why it works it doesn't become
something which you form an opinion about. It just is what it is.


This is condescending and adds nothing to the discussion.

Explain why I'm wrong: I'm saying that until you know how much time
your application is spending in a specific spot of code, you _don't_
know if its worth obfuscating the code in order for greater efficiency.
You don't even know _if_ obfuscating the code will lead to greater
efficiency: The compiler may optimize your code for you.
One thing is (probably) certain: The original way the code
was written is easier to read and change.


Yeah ok, so did you notice that the title of the web page was not
"Guidelines for making maintainable readable code"? You apply
optimization in just enough doses to deal with your bottlenecks. I
would have thought everyone knew this already.


But you never showed that it *was* the bottleneck. It makes as much
sense as deciding your automobile isn't running well and then putting
in a new catalytic converter.

If you improved your performance, it was by luck, not skill. You may
have decreased the maintainability of the code for no real performance
gain.
As Knuth said: Premature optimization is the root of all evil.


Yes ok, well Knuth doesn't write 3D video games. And he cleverly put
the word "premature" in there. That's like saying "eating too much
food is bad for you" -- that doesn't mean food is bad for you.


What you seem to be doing is operating under the mistaken impression
that ordering instructions in certain ways will always lead to faster
code: C does not state that a specific set of instructions will be
faster.

Therefore the speed of execution is dependent on your environment,
your compiler, and the phase of the moon. :)

Until you know where the bottlenecks are, you can't remove them.

PS: Your sig deliminator is screwed up: its dash-dash-space-return

--
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
Nov 14 '05 #47

P: n/a
Jesse Meyer wrote:
we******@gmail.com <we******@gmail.com> wrote:
Jesse Meyer wrote:
we******@gmail.com <we******@gmail.com> wrote:
> ---
> Paul Hsieh
> http://www.pobox.com/~qed/

I visited your webpage.

One the third example that you gave for optimizations (if
statements within for loops), did you ever _benchmark_ the
code you complained about?
Yeah -- its called branch mis-predictions. Its a question of how
many of them you want to pay for. Its actually just a very simple
math problem.


You don't have a benchmark: That's a theory. [...]


I don't have a benchmark that I can share publicly. Remember this
example was used in some seriously proprietary code.
[...] The theory is that your compiler is converting your code
into inefficient instructions,
Well its deeper than that. A modern compiler can use a technique
called "unrolling" to speed up loops. Indeed many modern compilers do
that today. But this is premised on the notion that inner loops are
simple, short, and can improve instruction density as a result.
Leaving an if-conditional in the inside of your loops can prevent your
compiler from being able to unroll the loop, or from gaining much
benefit by doing it since it leaves extraneous instruction in the
execution path. Athlons are really fast at execution NOPs, but it
still has to decode them before it gets to other instructions.
and that set of code is where your program is spending a large
amount of time in that segment of code.
That isn't something I assume that this sort of code will do all the
time. Rather I assume that you've discovered some bottleneck in your
code, it looks like this, and you might want to do something about it.
Now, I don't know what processor you are running on, but with
the environment you are speaking of (Redmond/games), it seems
that it would probably be from the x86 line.
I'd like to point out that Nintendo has a base of operations in Redmond
WA as well. ;)
[...] While processor architecture isn't one of my
strengths,
Ah. So if you don't know about it, then you should assume it isn't
there right?
Obviously, this is all dependent on what they were actually
doing, the compiler, the OS, the machine in question, and the
phase of the moon, but perhaps they profiled their performance
critical code and came up with similar numbers.


It also depends on some degree of understanding by the
programmer. Its like math -- once you understand how and why
it works it doesn't become something which you form an opinion
about. It just is what it is.


This is condescending and adds nothing to the discussion.


No, questioning what it is, adds nothing to the discussion. This
technique is a form of hoisting. Most people do not question hoisting
as a valid method of optimization (besides some expectation that maybe
your compiler will do it for you.) But for some reason you are. How
do you expect me to respond to this?
Explain why I'm wrong: I'm saying that until you know how much
time your application is spending in a specific spot of code,
you _don't_ know if its worth obfuscating the code in order for
greater efficiency.
This is non-sequitor. After you figure out where your bottlenecks are
you have to have some approach to optimizing them (after considering
removing them or rearchitecting your code.) The technique I showed is
one such technique. So the argument that it might not be where a
bottleneck is, is not an argument against the effectiveness of a
technique which is only meant to be applied where bottlenecks are.
You don't even know _if_ obfuscating the code will lead to greater
efficiency: The compiler may optimize your code for you.
The reason I brought the technique up in the first place is because I
*know* compilers will *not* do that sort of optimization. This
particular kind of hoist is, in general, too hard for the compiler to
know how to do correctly, and beyond reasonable capabilities of proving
that it is correct (a C compiler in general, cannot prove that a
variable will remain constant unless it has some a priori knowledge
about the aliasing of all the variables used in the vicinity of the
code). I've looked at this with the best compilers in the industry --
its just too hard of a problem for them.
One thing is (probably) certain: The original way the code
was written is easier to read and change.


Yeah ok, so did you notice that the title of the web page was not
"Guidelines for making maintainable readable code"? You apply
optimization in just enough doses to deal with your bottlenecks.
I would have thought everyone knew this already.


But you never showed that it *was* the bottleneck.


That's because whether or not it is a bottleneck will depend on what
circumstances it will be used. Its easy to show scenarios in which
that same code either is or is not a bottleneck. Its independent of
the technique. This comment can be applied to any optimization
technique.
If you improved your performance, it was by luck, not skill. [...]
This makes no sense whatsoever. I have never improved the performance
of code by luck -- I have no idea how that could ever happen. You've
engineered things by luck? That's an interesting trick I'd like to
see.
[...] You may have decreased the maintainability of the code for
no real performance gain.
Ok, I see -- you're saying that we're not supposed to know the
performance of the output of any code generated by a C compiler, and
yet you know *FOR SURE* that there is no real performance gain from
this technique?
As Knuth said: Premature optimization is the root of all evil.


Yes ok, well Knuth doesn't write 3D video games. And he cleverly
put the word "premature" in there. That's like saying "eating
too much food is bad for you" -- that doesn't mean food is bad for
you.


What you seem to be doing is operating under the mistaken impression
that ordering instructions in certain ways will always lead to
faster code:


Really? Where did I say or even imply this? I encourage you to scour
10+ years of my USENET postings or any publication or webpage (you can
use iarchive to find all my old stuff going back to about 1997) for any
such suggestion by me.
[...] C does not state that a specific set of instructions will be
faster.
*You* brought content from my web page into this newsgroup. You
understand? In the twisted universe of comp.lang.c, you can't know the
performance, reliabliity, or behavior of anything. In my universe, I
deal with things more concretely. Get it?

If you got a problem with my conceptions of C or how C relates to the
real world, then why would you go out of your way to voluntarily bring
that content from way over on my webpage into this newsgroup?
PS: Your sig deliminator is screwed up: its dash-dash-space-return


Google is screwed up. My life does not revolve around reverse
engineering google.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 14 '05 #48

P: n/a
we******@gmail.com wrote:
Jack Klein wrote:
On 13 Feb 2005 14:13:25 -0800, "Mysidia" <my*****@gmail.com> wrote:
C is not the best at portability, according to the more
modern relative definition of portability...
You mean where *semantics* get added to the definition?
Java for example is supposed to provide automatic portability
(What you lose in the process is performance and some basic
capabilities: things you can do portably are limited by the
high level SDK available, (and sometimes the high level SDK
isn't good enough)


Except Java provides no portability at all to any platform that
isn't at least 32-bits with a multi-tasking GUI environment.


What are you talking about? A VM can emulate multitasking -- an
underlying OS which does so is irrelevant (in fact, I would be curious
to know, if in fact, the Java spec *REQUIRES* the multitasking to be
emulated, so that race conditions are limited to VM instruction
granularity.) Interfacing with GUI environments has to be done with
some kind of native method rig up, and again is not a gating factor in
the ability to run Java.


So how do you do this native rig up on a system that does not even
*have* a display?

<snip>
[...] C on the other hand, does.


C requires the existence of files/stdio, and a system timer. Voting
machines can arguably be considered more secure if they do *NOT*
contain any system timer (consider software which waits for the
election date, or well past the start of a real election before
enacting a "flaw" -- a little hard to do without a timer).


No, C only requires that for a *hosted* implementation. This is one
reason why the C standard talks about both hosted and free standing
implementations.
There is a C compiler, or more likely several or dozens,
for virtually every processor architecture in existence,
from 8-bit microprocessors and microcontrollers to 64-bit
supercomputers.


Yes, but I think the OP's point is that no pair of any such compilers
accepts the same set of source inputs and does not generate
semantically compatible output for the intersection of code that is
common.


Strange that so many of us (including me) are working on SW that uses
common source files and behaves the same on multiple implementations.
Also strange that I managed to debug some embedded SW by writing a test
harness for it on a Silicon Graphic workstation and then building and
running the module on the workstation before taking the *unmodified*
sources back to my normal development system and compiling them *still*
*unmodified* for a DSP processor and it worked.
No new processor or controller is ever introduced without
some C compiler being available these days.


I am aware of at least one smart card that was -- they implemented a
picojava instruction set for it. Think about the complexities involved
in architecture design and bring up -- there can't possibly be any
since they have most of it specced out for them already.


I've seen at least one C to Java Bytecode compiler (I don't know how
complete or conforming it is) so if it runs Java Bytecode then there is
at least one C compiler (however bad) that targets it.
The core of C is the most portable language in existence, has
been for a long time, and will be for a long time to come.


You misspelled *least*. Lua, Python and Perl, for example, are *FAR*
more portable. I think the only two languages I know of which are
*less* portable than C are assembly and Basic.


So how come I have a Java application that will run on SCO 5.0.7 but not
on SCO 5.0.5?

Can you provide me with a Java implementation for the TMS320C25 I used
to write SW for? How about the Perl implementation? This processor only
has a *maximum* of 64K program address space and 64K data address space
and our target HW had at most 8K of each.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #49

P: n/a
[ Snip long discussion ]

I think we must agree to disagree here.

Sorry.

--
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
Nov 14 '05 #50

93 Replies

This discussion thread is closed

Replies have been disabled for this discussion.