--- In msp430@msp4..., "grahamgollings" <lmsbv@m...> wrote:
> [SNIP] If 
> I can make a suggestion. I did look at your website a few weeks ago 
> and was a bit overwhelmed, and gave up after a short while. Why 
> don't you add a button CODE SAMPLES on the home page and give a few 
> simple examples like you did here. That is all I was looking 
> initialy for and if they were there that might have given me the 
> interest to study the site in more detail. 
That's a good idea. We have innumerable code samples in the actual
distributions (and some in the manual, too), but as you point out a
more direct presentation would benefit everyone involved. I'll see
what I can do.

--Andrew
 

On Wed, 25 Jun 2003 21:57:36 -0000, you wrote:

><snip>
>I notice that there is a ominous silence from the C suppliers to our 
>posts, I wonder if they are listening? Anyway, I wish you the best 
>in your quest.
><snip>

I haven't ever seen anything from pumpkinin, but I've talked a
little with Andrew on comp.arch.embedded about some interesting,
tiny details regarding an O/S I've written.  Seems very similar
in many regards, which probably shouldn't have been surprising
to me given that the tight constraints of small 8-bit CPUs
severely limits choices.

Anyway, when I get a chance to clean up and vet the work more,
I'll release it into the public domain.  Or something else so
that no one else can figure out some legal shenanigans to
prevent me from distributing my own code to anyone I please,
when I please, or to get their dander up and sue me because my
code is perceived to be a business inconvenience to them, while
protecting me from folks who might misuse the code to write
nuclear submarine launch sequences and then sue me for my
ignorance and negligence.  Sheesh.  I've almost scared myself
out of the idea!  What's this world coming to?

Hehe.  Anyway, most of it is highly configurable at compile
time, such as selecting singly-linked or doubly-linked queues
(the code uses macros in order to keep a common, cleanly
designed module untouched, regardless), the ability to use flash
for ROMable portions of the process table, the ability to
specify (or not) the availability of a real-time clock, whether
or not a sleep queue is desired, process priorities or not,
round-robin pre-emption behavior with quantums for processes of
equal priority (all are equal if no process priorities) -- or
just a cooperative model, optional semaphore support and limits,
and of course, the number of processes.  Very small footprint,
in fact.  Almost no assembly required.  ;)

I'm not going to sell it, though.  It's a work from love and joy
and I'd do it if no one paid me -- hmm, no one did pay me, come
to think of it.  I'm not interested in making it a business out
of it, either.  I've got other things in my life.

But of course, this also means I'm not on a schedule so don't
count on anything from me, either.

...

By the way, I think that the semantics of a simple operating
system, even if it is only the most elementary, cooperative task
switcher and only supports swapping stacks and none of the
static data contexts (shared statics -- often called a
"thread"), is pretty darned important in writing embedded
applications.  Even if the main operation is simply
input-->process-->output, there is usually some kind of
ancillary thing going on like: monitoring switches or keys,
handling RS-232 query and command parsing and putting out query
replies, or some other kind of "background" to the main idea.
It greatly improves readability and maintenence, I think, when
used with just a little bit of basic knowledge.

Separately, there are a number of common cases where I don't
really need separate threads but just an elementary coroutine
method.  The thread semantic works fine for this, but it's a
little more than I sometimes need.  These kinds of coroutine
arrangements occur often in embedded work, but C doesn't have a
syntax to support the semantics.  They go under many names, but
I think of them as "iterators" and they would be *very easy* to
add to a C compiler syntax and semantic parser.  But they
wouldn't be standard, that's for sure.

If compiler vendors would consider including some kind of O/S
for differentiating themselves in the embedded world, I'm not
exactly sure how that would work -- particularly, as pumpkininc
may have the only going concern here for small processors and if
all the compiler companies decided to include it then what's the
point?  But they might consider the idea of providing certain
extensions to the language, as it might differentiate their
products for embedded use.  In this narrow area, I'd be more
than happy to have the option of deciding for myself, whether or
not to use the feature.  And knowing that I had the option might
make a buy-decision for me.

Jon

--- In msp430@msp4..., Jonathan Kirwan <jkirwan@e...> wrote:

[SNIP lots of good stuff removed]

> If compiler vendors would consider including some
kind of O/S
> for differentiating themselves in the embedded world, I'm not
> exactly sure how that would work -- particularly, as pumpkininc
> may have the only going concern here for small processors and if
> all the compiler companies decided to include it then what's the
> point?  

Well, look at it this way: If C had multitasking in it ** as part of
the standard **, then clearly a compiler vendor that didn't include
the libraries would be at a disadvantage to those who did. Imagine how
different this discussion would be if multitasking were a standard
part of C -- potential compiler buyers would look askew at a compiler
without multitasking libraries. And I bet we would have more empathy
with the Forth guys. Multitasking extensions would be even more
elegant, but ANSI C doesn't have any.

Salvo isn't part of ANSI C, of course, but many of us here feel
strongly that a structured, multitasking / multithreaded approach is
of great benefit to many applications and programmers. Compiler
libraries (and Salvo is just another library for most users) are
really just parts of a toolset to get the job done faster / cleaner /
more portably than if you had to do it from scratch. I certainly don't
want to write floating-point routines ...

I have seen people make decisions on compiler purchases based on how
complete the compiler's library offering is ... after all, there are
ANSI compilers for embedded targets out there that don't support
printf() and va_arg() at all ... Not that printf() is terribly
important for embedded work, but most people would like to have one if
only to do a simple "Hello, world.\n" test, even if only in a
simulator with simulated terminal output. If the other compilers for
the same audience have printf(), then that's a strike against the
compiler that lacks it (all other things being equal).

--Andrew

Hello John,

I appreciate your comments and agree with much of what you say. But 
until C gets as productive a Forth I dont think that we will bother 
to try C. We actually outsource the programming to 3 - 5 Forth 
programmers 2 of which are in India and very competitive. We send 
them hardware and they do the rest.
 
>The issue is one of code space and storage.  Parts
like the 
>MSP430F123 have 256 bytes of RAM.  There's not much room for Forth 
>words once you allocate a stack and a few bytes of data for the 
>interpeter.

As we are talking about 430's I will provide a little information 
about where we are now. In fact we are waiting for another compiler 
company to finish their Forth system. I dont know how that 430 system 
will stand up, but their other targets such as ARM, H8 series produce 
20 - 40% less code than the best C compiler. A notable project was to 
install a game package in a popular cell phone when the C compiler 
used ran out of rom.
 
Anyway the 430. The compiler I use today produces a Multitasking 
talker which is placed in high rom. As is, it takes about 550bytes of 
flash and 100 bytes of ram. The Rom required can be reduced by 
removing the multitasker and other utilities. But in fact 60% of the 
code is useful for an application. The ram required can be reduced to 
about 30bytes. A bare bones system can be reduced to 10 bytes ram.

The target talks to the PC via RS232 @ 38k baud. The PC has the Forth 
compiler, and its job is to compile and download binary code to the 
target, which happens in seconds. The code can then be tested on the 
target and any peripherals attached can be played with from the PC. 
John, I write this not for you because I know you know this, but for 
anyone else that might read this post.

This method does burn Flash, which as you say is fatiguing, but in 
reality this is not an issue. I have probably recycled the F123 Flash 
a few hundred times. I dont think that this is an issue, if it is I 
just ask TI for another sample...

I totally agree that Forth is a sub-culture and in the real world 90% 
of seats are C or assembler, 5% is Forth - I read somewhere. The rest 
is a dying breed Modular2, Pascal, even Java never really took off.

As you know the main difference between C and Forth is methology and 
in this area they do differ considerably. I cannot say which is the 
best, and your commercial argument is correct. But horses for 
courses, nothing is perfect.

What I would like to know is how you work with C. Lets say you have a 
target PCB with an LCD, push buttons, and CAN bus chip attached.

What is the sequence, I see you can write the code, but how does the 
rest go, how do you play with the 430 and it's peripherals for 
instance?

Kindest regards
Graham. 

Graham,

> As we are talking about 430's I will provide
a little information 
> about where we are now. In fact we are waiting for another compiler 
> company to finish their Forth system. I dont know how that 430 system 
> will stand up, but their other targets such as ARM, H8 series produce 
> 20 - 40% less code than the best C compiler. 

Ok, so you're talking about Stephen's compiler, then, but using one
from
FI?  I'd have to challenge the 20-40% less code, though.  Stephen's
compiler won't do the oprimizations that many C compilers do as a matter
of course, such as register allocation.

> A notable project was to 
> install a game package in a popular cell phone when the C compiler 
> used ran out of rom.

This is more a reflection on the quality of the C compiler, I'm afraid.
Stephen's compilers are very good, nevertheless.  Both FI and MPE
compilers are now going subroutine threaded, so performance is notching
up.

> I totally agree that Forth is a sub-culture and in
the real world 90% 
> of seats are C or assembler, 5% is Forth - I read somewhere. The rest 
> is a dying breed Modular2, Pascal, even Java never really took off.

This must be in an embedded context; I doubt 5% is Forth at all if you
count the number of developers active globally.  Gee, I'd expect more
people know how to code in Perl than do in Forth.  Java is big in
server-side systems, and really has taken off (but not for mainstream
application development for Windows).

> As you know the main difference between C and
Forth is methology and 
> in this area they do differ considerably. I cannot say which is the 
> best, and your commercial argument is correct. But horses for 
> courses, nothing is perfect.

Forth is a great language for tinkering in,  Elizabeth Rather and
Stephen Pelc will, of couse, disagree.  There is an ISO and ANSI
standard for Forth but, if you take a look, there is no standard tasking
interface mentioned there.  Even cross compilation is not addressed by
the standard, apart from the notional RAM and ROM words.  If you were
given an ANSI-compliant Forth compiler, I suspect you'd be able to do
very little useful with it.

-- Paul.

Hi Paul,

> I'd have to challenge the 20-40% less code,
though. 
> This is more a reflection on the quality of the C compiler, I'm 
afraid.

No this is not correct, several compilers were tried, and I dont 
think it was anything to do with optimisation anyway.
 
> This must be in an embedded context; I doubt 5% is
Forth at all if 

Yes I was meaning embedded app's.

> there is no standard tasking interface mentioned
there.

At least there is a tasking interface, I personally dont care 
whether it is to any standard, although that would be nice.

Graham.

Graham,

> > I'd have to challenge the 20-40% less
code, though.
> > This is more a reflection on the quality of the C compiler, I'm 
> afraid.
> 
> No this is not correct, several compilers were tried, and I dont 
> think it was anything to do with optimisation anyway.

Greenhills is rumoured to be the best; however, ARM customers seem to be
moving to Thumb, and now Thumb-2 has made its presence known.  However,
all these benchmarks are done using EEMBC and "big" systems.

> > there is no standard tasking interface
mentioned there.
> 
> At least there is a tasking interface, I personally dont care 
> whether it is to any standard, although that would be nice.

There is no tasking interface in the ISO document at all.  You might get
one with your product, but you won't with a bog standard ISO
implementation.

-- Paul.

Hi graham, don't know your age from the posts, but if you're old
enough
and remember the days before IBM dumped the PC on us. The PC world (as
in personal computer, not IBMs world view) was a very different and
anarchic place, (much more fun than it is today) with many amazing
machines. Some so advanced the PC world really didn't catch up for many
years (perhaps it never has?). Anyway one of the nicest toys around was
the Jupiter Ace. Not only was it a tiny machine physically but it was
designed around FORTH. FORTH was fairly common in that era. I used it a
lot on the BBC Model B, mainly for control applications. I haven't used
it since, but it was perhaps the first microprocessor high level
language I learnt. (followed by Lisp, Prolog, BASIC and a few others)
and far more elegant than the mainframe languages I'd become used to
such as COBOL, FORTRAN and ALGOL. Now I stay with assembler for
efficiency and speed, and C on the odd occasion when these don't matter.
FORTH seems to fall somewhere between the two in size and execution
speed, hence, for me, at least, the marginal gains over C aren't worth
the effort.

Just my old rheumy view of the world.

Al

grahamgollings wrote:
> 
> Hello John,
> 
> I appreciate your comments and agree with much of what you say. But
> until C gets as productive a Forth I dont think that we will bother
> to try C. We actually outsource the programming to 3 - 5 Forth
> programmers 2 of which are in India and very competitive. We send
> them hardware and they do the rest.
> 
> >The issue is one of code space and storage.  Parts like the
> >MSP430F123 have 256 bytes of RAM.  There's not much room for Forth
> >words once you allocate a stack and a few bytes of data for the
> >interpeter.
> 
> As we are talking about 430's I will provide a little information
> about where we are now. In fact we are waiting for another compiler
> company to finish their Forth system. I dont know how that 430 system
> will stand up, but their other targets such as ARM, H8 series produce
> 20 - 40% less code than the best C compiler. A notable project was to
> install a game package in a popular cell phone when the C compiler
> used ran out of rom.
> 
> Anyway the 430. The compiler I use today produces a Multitasking
> talker which is placed in high rom. As is, it takes about 550bytes of
> flash and 100 bytes of ram. The Rom required can be reduced by
> removing the multitasker and other utilities. But in fact 60% of the
> code is useful for an application. The ram required can be reduced to
> about 30bytes. A bare bones system can be reduced to 10 bytes ram.
> 
> The target talks to the PC via RS232 @ 38k baud. The PC has the Forth
> compiler, and its job is to compile and download binary code to the
> target, which happens in seconds. The code can then be tested on the
> target and any peripherals attached can be played with from the PC.
> John, I write this not for you because I know you know this, but for
> anyone else that might read this post.
> 
> This method does burn Flash, which as you say is fatiguing, but in
> reality this is not an issue. I have probably recycled the F123 Flash
> a few hundred times. I dont think that this is an issue, if it is I
> just ask TI for another sample...
> 
> I totally agree that Forth is a sub-culture and in the real world 90%
> of seats are C or assembler, 5% is Forth - I read somewhere. The rest
> is a dying breed Modular2, Pascal, even Java never really took off.
> 
> As you know the main difference between C and Forth is methology and
> in this area they do differ considerably. I cannot say which is the
> best, and your commercial argument is correct. But horses for
> courses, nothing is perfect.
> 
> What I would like to know is how you work with C. Lets say you have a
> target PCB with an LCD, push buttons, and CAN bus chip attached.
> 
> What is the sequence, I see you can write the code, but how does the
> rest go, how do you play with the 430 and it's peripherals for
> instance?
> 
> Kindest regards
> Graham.
> 
> 
> .
> 
> 
> 
> ">http://docs.yahoo.com/info/terms/

Hi Al,

I will keep you guessing agewise! (for now anyway) The 1st micro that 
I got involved with was a CPM machine, It had 32k ram a Z80 (don't 
remember clock speed), a telex machine to edit and punch tape to. 
Writing assembler in binary format. I later replaced the punch tape 
with a cassette tape recorder. Then the final step, I got 2x 8" 
Shutgard floppy drives and upgraded the ram to 128kb ( blistering 
speed) That got me into assembler coding at source level. I will 
never forget how fast the 1st files opened and saved on those 8" 
drives.

As I got more advanced I ported a Pascal and later helped write a C 
compiler to run under CPM to make embedded applications. No debuggers 
in sight. This must have been 35 years ago........

Which probably makes me an early pioneer of C in 8bit micro's !

> Just my old rheumy view of the world.
Amen.

Next I got into the 8051 series and discovered Forth, I did 
experiment with C on the 8051 and even bought an expensive compiler 
but just didn't get on with it.

Presently I use ARM and the 430. Philips have a new chip 128kb Flash 
60mh/z ARM - LPC2106 - nice.

Kindest regards

G.

On Thu, 26 Jun 2003 05:26:31 -0000, you wrote:

>--- In msp430@msp4..., Jonathan Kirwan
<jkirwan@e...> wrote:
>
>[SNIP lots of good stuff removed]
>
>> If compiler vendors would consider including some kind of O/S
>> for differentiating themselves in the embedded world, I'm not
>> exactly sure how that would work -- particularly, as pumpkininc
>> may have the only going concern here for small processors and if
>> all the compiler companies decided to include it then what's the
>> point?  
>
>Well, look at it this way: If C had multitasking in it ** as part of
>the standard **, then clearly a compiler vendor that didn't include
>the libraries would be at a disadvantage to those who did. Imagine how
>different this discussion would be if multitasking were a standard
>part of C -- potential compiler buyers would look askew at a compiler
>without multitasking libraries. And I bet we would have more empathy
>with the Forth guys. Multitasking extensions would be even more
>elegant, but ANSI C doesn't have any.

I think I'm following, but I'm not sure.

There is a gamut to the semantics I'd like to see available in
my own development toolset, which I've had to fight time and
again.

One of them is just very basic thread semantics, with an option
for pre-emption when I can afford it, and the possibility of
semaphores and a simple process message.  But the core of what I
have to repeatedly build for myself is a simple, cooperative
thread semantic with common static data and separate stacks.  I
often can get away without the extras, like a sleep queue, for
example, or pre-emption.  More, I apprehend the difficulties
that some architectures might present in implementing separate
stacks for threads (some Microchip PICs come to mind here) and I
do *not* believe that this belongs in the compiler vendor's
realm of responsibility.  In fact, despite my own affinity for
thread and process semantics, perhaps some of what's made it
possible for C to succeed as well as it has is exactly that it
didn't (and still doesn't) include such features.  I think these
things are better handled with crafted libraries, where
possible, not additions to the language itself.

The other of them is the idea of iterators.  Here, I think the
compiler folks should intervene.  Only a single stack is
required to maintain an alternating context, operated similarly
to a coroutine.  Nothing is required from the processor, which
isn't already required in order to implement C's existing
semantics.  No new battles need to be fought.  And the context
can really only be handled well by the compiler.  It's a mess,
as I've discovered over and again, trying to do this as a
library.  But for the compiler folks -- dirt easy, I imagine.
And having them would cover some of that for which I use an
operating system.

So, I agree that having additional features in a compiler
*could* be a marketing advantage, if the advantages are broadly
helpful.  We could debate "library implementation vs language
semantics" for each feature, but regardless of where the
features wind up I will look at what's provided and a broad
range of other factors before making a decision.  If it includes
thread semantics in a library package and, after looking at the
details, it looks reasonably well-crafted, then that may play a
part in my buying decision.  More so, if the compiler vendor has
managed to use their buying clout (should they have any) in
order to make a better deal with the library supplier than I
could have done on my own.  If the package price is cheaper than
the individual parts and I feel the need for both, then that
certainly will get my attention.

>Salvo isn't part of ANSI C, of course, but
many of us here feel
>strongly that a structured, multitasking / multithreaded approach is
>of great benefit to many applications and programmers. Compiler
>libraries (and Salvo is just another library for most users) are
>really just parts of a toolset to get the job done faster / cleaner /
>more portably than if you had to do it from scratch. I certainly don't
>want to write floating-point routines ...

Hehe.  I've written them, actually.  As well as a complex-FP
input, complex-FP output FFT on an integer processor without the
benefit of hardware and taking every step I reasonably could to
optimize -- no generic use of stock library calls, for example,
but a numerical analysis of each set of operations to look for
"opportunities."  I guess, there are times you need to get your
hands dirty and times you don't.

>I have seen people make decisions on compiler
purchases based on how
>complete the compiler's library offering is ... after all, there are
>ANSI compilers for embedded targets out there that don't support
>printf() and va_arg() at all ... Not that printf() is terribly
>important for embedded work, but most people would like to have one if
>only to do a simple "Hello, world.\n" test, even if only in a
>simulator with simulated terminal output. If the other compilers for
>the same audience have printf(), then that's a strike against the
>compiler that lacks it (all other things being equal).

Yes, agreed.  But the question is... do all customers have to
pay some extra money so that the few who need the features can
have them for less?  Personally, I'd rather not see Quadravox up
their price point (or delay lowering it) just because they
bought themselves into a "feed this guy's children" contract and
have to force all of us to carry the load.  There are those who
will never use thread semantics because, frankly, they just
don't know what they are good for and have little experience
with them.  People use what they know, mostly.

However, an earlier point I'd made (which I think you are
responding to, here) was to ask the question "If all compiler
vendors do the same thing, what's the point?"  To be more
explicit, "If pumpkininc is the only viable, commercial small
O/S going and if all the compiler vendors enter into the same
arrangements with pumpkininc because of that fact and because of
perceived competition if they didn't, then there would be no
differentiation between them and the upshot would be that we
customers of these compilers would all be feathering
pumpkininc's bed even though some wouldn't even know it."

In other words, if everyone's doing it then it's not a
differentiating element for competition.  But everyone is then
paying for it.  I think folks like Michel and Richard have to be
considering the possibility that if they decide to partner up
with you, *and* if that turns out to make a difference in sales,
that their competition would then simply do the same thing in
order to negate the difference.  That kind of battle would be a
great thing for you, if you can manage it.  You'd get a piece of
the action you didn't have before.  But I'm not sure that would
necessarily be good for their customers.  That's the question in
hand.

To me, buying a compiler from Michel, for example, and then
buying your o/s as separate purchases could make sense for an
application.  The *only* reason I can think of why I might want
to buy both a compiler *and* an o/s from the same supplier (for
example, if Michel included pumpkininc's software) would be
either to save some of the total outlay in cash or else to have
a single point of contact for support.  I don't think Michel
would offer direct support for your libraries nor you, for
Michel's compiler, so that's probably out.  And I see no reason
why Michel or you would want to undercut your profit structure
to my benefit if I purchased both.  What would either of you
hope to gain from this?  Additional business you wouldn't
otherwise get?  Not if it's an elective customers can choose to
buy, or not.  The only way that works out for you both is if
some customers are forced to buy something they might not have,
otherwise.  Then, and only then, does the discounting make sense
to you folks in order to broaden a base.

Or am I missing something?

Jon


P.S.
Just by way of wandering a bit...

If there is a clear strategy which works to get more people
using useful features which really make a difference in writing
applications, to aid maintenence and readability, to extend the
life of real products and reduce the efforts required to add
changes and the risks of doing so... then *everyone* benefits.
But just dropping in a new library doesn't, by itself, get you
there.  It'll take lots of education, as well as having the
features themselves, to do it.  So it's the educational facet
which, to me, is as important than the details themselves.  But
maybe pumpkininc is already doing it's part here.  If so,
perhaps nothing more is to be done.

On another note, I really would look at compilers which offered
some of the semantics I've hinted at.  For example, thread
semantics to me is broadly helpful -- it's really hard to
imagine something more than a toy application which wouldn't
gain some clarity in a few places from its use.  I'd like to see
*more* people become familiar with and then use these elements,
so I'm generally supportive of the idea of having them in the
toolbox.

Consider the impact of a simple RS-232 ASCII command parser on
the basic flow of input->process->output of a measuring
instrument.  It's trivial in concept, really -- writing a
recursive descent parser.  But your main measurement activity
must continue, so what happens when you go off to process a few
characters have eaten up the only 4 characters currently in the
receive buffer and have to wait for more?  You are down in some
nested routine or else buried in an 'if' or 'switch' and
suddenly need to save the current state so you can return to
this place when next some characters are available.  What a pain
that is!  And now imagine this, adding in a polled keyboard
scanner with similar issues.  As the product develops, new
features and/or hardware is added, the whole thing becomes a
nightmare to remember and keep track of.  State has to be saved
and restored.  It's exactly this which is rather seamless with
processes (and 'cooperative' work fine for many such uses.)  And
relatively immune to change as well as being easily read and
updated by others who didn't write the code.

It's manageable in a variety of other ways.  But there is just
about nothing quite so simple as a call to switch(), just when
you realize there is nothing more to do for now.  When it
returns -- there you are, right back in context and ready to
continue.  It doesn't get much simpler.  And this need isn't
uncommon even in small, embedded products.

There are alternatives.  One can set up state machines, for
example, in an attempt to clean this up a little without using
threads.  Or go to the trouble of saving one's place in the code
so that it can be restored again the next time, but "by hand" so
to speak.  But almost anything I do would stand to benefit in at
least one place from having simple thread semantics, because
they make this a no-brainer to handle and the modules are
relatively clean, easily understood, and easily maintained in
isolation of the rest of the system.

I wouldn't argue to put thread and process semantics into the
language syntax and semantics.  A library arrangement is the way
to go, from experience.  It works, as has been demonstrated time
and again.  But iterators *are* a compiler feature -- as I've
learned through struggling to build them as libraries, instead.
There, the compiler vendor can do so much more and at so little
expense.  Libraries just don't cut it here.

Customers don't have to use these features, of course.  If it's
important to their development to avoid special, custom features
then they should be able to.  But in the kind of embedded work I
often do (very small CPUs, low power, cost sensitivity, and a
host of other confounding and competing needs), just about
everything is specialized -- even what I can use and cannot use
from the libraries varies from compiler to compiler vendor, so
there's no banking on portability.  And, in any case, I simply
cannot afford the price of generic C code for generic processors
living in generic cluster of external features.  The cost
pressures just don't allow unthinking generality.  When all is
said and done, often the only thing I get portability from are
the C math expressions.  And even there, if there's FP involved,
that's a shot in the dark.  Portability of code for the existing
product just isn't as much a concern as getting the right
features.  We just pack away the compiler and the application
code on CD and unearth it when needed.  I want the compiler to
produce correct code and provide the semantics which are well
matched for the application being written.  And it turns out in
work I do, thread semantics and iterator semantics are two areas
I'd like to see -- one in the library, the other in the language
-- because that's where they will do the most good.  (I'd also
like a host of other features which are harmless to those not
using them, like namespaces, link-time constants, ...  but don't
get me started.)

Oh, well.  I'm dragging on.  Sorry about that.