Re: -funsafe-loop-optimizations

[kaih at khms dot westfalen dot de (Kai Henningsen)]

schlie@comcast.net (Paul Schlie)  wrote on 02.01.05 in <BDFD8FA3.873E%schlie@comcast.net>:

> > Kai Henningsen wrote:

[ as an example of why portability in an absolute sense only matters  
rarely ]

> > (For example, how many programmers outside the small end of the embedded
> > market still care that int might be 16 bit? Assuming at-least-32 is "not
> > portable" - but very, very common; in fact, I believe it's been in the GNU
> > coding guidelines since long before this was confined to the embedded
> > market.)

There's a reason I used the exact wording I did use:

> Well considering the fact that most of the worlds processor consumption (by
> orders of magnitude), are based, and likely will continue to be based 16-bit
> or less processor architectures, which not only care about 16-bit or less
> ints and pointers, but rely on them; it should likely be considered
> sufficiently significant to warrant concern. (although fortunately, most
> optimizations related to overcoming inefficiencies of deeply pipelined
> larger machines are largely irrelevant on smaller lightly pipelined
> architectures with closely coupled memory sub-systems).

Well yes, that is the small (as in very restricted cpu) end of the  
embedded market that I explicitely excluded above.

Incidentally, how often does one *need* portability to that part of the  
market for software developed for 32 bit cpus? If anything, I'd expect the  
opposite direction - changing to a larger cpu and porting the software.  
The kind of software that typically gets developed for 32 bit cpus is  
usually completely impossible to port to 16 (or even 8) bit cpus anyway -  
for one thing, it can't usually live in 64KB memory (and many of those  
cpus can't even handle that much) unless it's been embedded from the  
start, and even then, you probably targeted that larger cpu for a reason.

And in fact, even for PC-style software, portability always sucked for  
less-than-32-bit cpus ... because it's really, really hard to have a  
truely generic os with enough functionality and still room for an  
application in that little memory. A complete, usable standard C89 library  
(and I don't mean the standalone stubs)? Well, I guess it's *possible* -  
how many projects (free or commercal) managed to pull it off? Anyone for  
C99?

The portability you need most at that end is not source portability, it's  
programmer portability. Source portability is much more interesting in the  
general computer area than in the embedded market, and even there limited  
portability is often enough.

Hey, portability to most of Intel-Windows alone gives you a *huge* market!  
And you know very well how many people are quite content with that.

Absolute compatibility isn't exactly only academic, but it's damned close  
to it.

MfG Kai