Re using BREAK in 'C'

[CDB-3]

:: Maybe I should just rename it to !C

Sounds catchy, but Lego already have NQC - Not Quite C for their
electronic brick mechatronic concept.

Colin
--
cdb, colin@... on 7/07/2009
 
Web presence: www.btech-online.co.uk  
 
Hosted by:  www.1and1.co.uk/?k_id=7988359
 

 
 
 
 

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[sergio masci-2]

On Tue, 7 Jul 2009, cdb wrote:

>
>
> :: Maybe I should just rename it to !C
>
> Sounds catchy, but Lego already have NQC - Not Quite C for their
> electronic brick mechatronic concept.

Yeah but do they have an ISO standard for it ;-)

Anyway what about:

C'
C-bar
D-
K
NJAL
C<<1
>C
.GT.C

Come on lets hear your suggestions :-)
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Marcel Birthelmer-2]

> Come on lets hear your suggestions :-)

Cb (C-flat)?
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Russell McMahon-4]

:: Maybe I should just rename it to !C

Sounds catchy, but Lego already have NQC - Not Quite C for their
electronic brick mechatronic concept.


I decided to suggest "YACLL" and looked to see what Gargoyle said.
Predicatbly, the name is already well used.

Here is a monolog apposite to the present discussions .
Feb 2008

    http://www.bitwisemag.com/2/The-Next-Big-Thing-In-Programming


 R
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

M.L. wrote:

>> On Mon, Jul 6, 2009 at 7:07 PM, sergio masci<smplx@...>
>> wrote:
>> And forgetting about optimisation completely, what about promoting
>> integers to floats?
>>
>> e.g.
>>        float   x;
>>        int     y, z;
>>
>>        x = y / z;
>>
>> here a decent language / compiler could see that the result result
>> needs to be a float and promot y and z to floats and perform a
>> floating point division.
>
> IIRC the C type is undefined ...

Not sure what you mean by "undefined"; the expression "y / z" in the
code above has a result type of int (both values are of type int).

> ... - in any case and you should typecast it to float.
>
> x = (float)(y/z);

This isn't changing anything. This cast is implicit already in Sergio's
code. The division is still executed as integer division, then the
result is cast to float. This is exactly what the first code above does.

I suspect you mean something like

  x = (float)y / z;

which explicitly casts y to float, then by the promotion rules
implicitly casts y and z to double and executes the division as double
division, then casts the result down to float. (IIRC... I don't do a lot
of implicit casting of floats; I actually almost never use float.)

Gerhard

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[M.L.-2]

On Mon, Jul 6, 2009 at 8:41 PM, Gerhard
Fiedler<lists@...> wrote:

>> ... - in any case and you should typecast it to float.
>>
>> x = (float)(y/z);
>
> This isn't changing anything. This cast is implicit already in Sergio's
> code. The division is still executed as integer division, then the
> result is cast to float. This is exactly what the first code above does.
>
> I suspect you mean something like
>
>  x = (float)y / z;

Yes, I did. I thought of that after the fact.

-
Martin

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[William "Chops" Westfield]

> I remember that when I first read about Ada, I thought that
> this would be the future. It didn't become the future... Ada
> compilers are too heavyweight, too complicated, too expensive,
> too "niche". Probably no way to implement a compiler for a
> small 8bit micro efficiently.

One of the problems is that Compiler writers (perhaps more accurately:  
"Language Designers") and the sort of low-level programmers who wrote  
and propagated a language like C don't seem to like each other, or  
even talk to each other very much.  So the language designers go off  
and do something, and the device driver folk, whether they're for 8-
bit micros or mainframes, sorta shrug and go off and do their thing in  
assembler, or invent their own language.

I don't find C's lack of stronger typechecking any more surprising  
than Pascals lack of boolean math, for example (no, sets are not the  
same thing.)

You see this sort of dichotomy all the time.  On the one side you have  
these expensive and huge languages (PL/1, Smalltalk, Ada, etc) with  
the CompSci PhD touting their strong type checking and semantic  
elegance and blah blah blah.  On the other side you have dangerous,  
simplistic, and hard to read languages (Assembler, C, Forth) with some  
hardcore developers mumbling about speed, power, fewer keystrokes.  
Sigh.

BillW

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Gerhard Fiedler wrote:
>> Those that developed their own useful Pascal variants saw them like
>> intellectual property that gave their platform a competitive
>> advantage.
>
> Looking at how things went, it seems like this was a bad choice. Maybe
> K+R et al weren't that incapable after all...

K+R were in a research setting where they didn't have to care about profit
or competitive advantage.  They had nothing to loose by letting everyone at
it, so you can't say if they did it due to deliberate thought or just lucked
into it.  I suspect the latter.

>> This was the prevailing mindset until the late 1980s when Sun
>> overtook the workstation market on the strength of openess.
>
> No, it wasn't. For some people, maybe, but there was an ANSI standard
> for FORTRAN that dates back to 1965. (This and the backing of IBM were
> probably two of the major factors for the popularity of FORTRAN.) If
> ANSI took up standardization efforts for C in 1983, there was a push
> to do this that started way before 1983. Something like this doesn't
> happen out of the blue. So the mindset to standardize was there.

Of course there were standards, but companies opening their proprietary
operating systems and large programs like compilers was certainly not the
prevailing way things were done.

> There is also an ISO standard for the original Pascal that dates back
> to 1983. But it seems that this standard wasn't usable; for a number
> of reasons, everybody implemented their own versions.

I'm guessing that didn't work because it was too late.  By 1983 a number of
proprietary Pascal version were already well developed.  A lot of code
existed in each version, so I'm guessing nobody wanted to have their code
orphaned.  Sometimes standards are set up as smoke screens.  Remeber OSF?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

William Chops" Westfield" wrote:
> I don't find C's lack of stronger typechecking any more surprising
> than Pascals lack of boolean math, for example (no, sets are not the
> same thing.)

I thought even the original teaching language had the boolean type and
boolean operators like AND, OR, and NOT.  Maybe they left out XOR because
that's implemented as a intrinsic function in Apollo Pascal instead of a
operator.  There aren't that many ways to combine 2 bits.  I'm not sure what
more you want.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

sergio masci wrote:

> I chose sin because to a great many people it is a black box which
> they can relate to rather than some complex function that I'd invent
> as an example.
>
> Yes the compiler writer could allow the programmer to attach a ton of
> attributes to a library function to help it understand the function
> better but that's not the point. The point is to make it simpler for
> a programmer to write good code that is easy to maintain - to allow
> the compiler to extract the necessary information from the function
> itself without the programmer needing to add extra attributes - which
> like comments might actually be at odds with the code and be wrong
> (yet something else to debug).

I was talking about standard libraries, where the programmer doesn't
have to attach anything. The difference between libraries in general and
standard libraries is that the standard libraries must conform to a
standard to be a standard library, not any more or any less than a
compiler. Of course such a standard in general doesn't define how it is
implemented, but it defines what it does.

> Let's try something a little bit more interesting:
> [...]
> main()
> {
> ...
> delete_item(pos, &len, arr);
> insert_item(pos, val, &len, arr);
> ...
> }
>
> Now how would you give the compiler enough information in the attributes
> of the functions to be able to automatically optimise the above into the
> equivalent of:
>
> replace_item(pos, &len, arr);

This function should have been part of the interface in the first place.
This is the tricky part of defining a good library interface: provide
the interface that makes sense.

> A far more concrete example would be that of having multitasking built
> into the language rather than as a bolt-on library. XCSB knows about
> multitasking and generates optimised code around it. You don't need
> to generate several stacks and functions that need to be re-enterent
> just in case they are being used in several tasks. Don't you think
> that's a benefit?

Of course. C for example lacks any multitasking specification; it wasn't
relevant at the time the C spec was created, because it was handled by
the operating system, exclusively. Now it's common for applications to
do multithreading inside the application, and this shows the
shortcomings of a suitable standardization.

But besides this, I think that what you are talking about is an
optimization. The compiler should have enough knowledge to be able to do
it, and it should be specified well enough so that multitasking features
are specified, but I still fail to see the big difference whether this
is specified as a standard library or as part of the compiler.

> I mean the fact that you can get tight efficient multitasking code
> written in a HLL to work on something as small as a 16F628?

People do it all the time. It is of course a feat to have this built
into the compiler. The real feat is, however, to design this and
standardize this in a way that it is efficient and suitable for
everything from an embedded application running on "bare metal" in a
16F628 to an embedded application running on a stripped down Linux in an
ARM to a desktop application running on Windows XP in a multicore
processor.

> This was a trivial example but consider a much more real case where
> the above code would actually exist in a library as part of the
> 'init' sequence of a module. Ideally the programmer would be
> insulated from having to build large complex static tables within
> his/her main line. This should all be taken care of by the library
> writer / maintainer.
>
> You must have come across some horrible libraries yourself where
> several things need to be declared as "#defines" before the
> corresponding header of the library is included into your main line
> for the sake of efficiency.

Of course. But this is just a side effect of a limitation of C, not of
the fact that this was in a library rather than in the compiler. Much of
this ugly preprocessor code you're referring to is due to the fact that
the C language doesn't specify much (if any?) compile-time evaluations.
To do this, people have to resort to the preprocessor. Complex
compile-time evaluations could/should part of a good language
definition; it would help a lot, especially on small systems. But IMO
this hasn't much to do with whether these calculations are defined in
library code or in something that's supported by the compiler directly.


> If you replaced the operators '=' and '*' with 'assign' and 'mult' such
> that the above was re-written as
>
> assign(&x, mult(j, 2));
>
> how would you give the compiler enough information on the above
> functions to be able to do the same level of optimisation as before?

If the semantics of assign and mult are clearly defined by a standard,
it could do the same optimizations.

> And forgetting about optimisation completely, what about promoting
> integers to floats?
>
> e.g.
> float x;
> int y, z;
>
> x = y / z;
>
> here a decent language / compiler could see that the result result needs
> to be a float and promot y and z to floats and perform a floating point
> division.

This may be what the programmer wants, or not. The compiler doesn't know
whether I want y/z be an integer division or a float division or a
double division. Chances are that if I had written this, it wouldn't be
what I want. But I don't write such code; I tend to use explicit casts
to make sure both the compiler and the human reader of the code know
what the code is supposed to do. If I could, I'd disable automatic
promotions in C and C++, so that I don't forget any explicit cast. Where
compilers have warnings for this, I enable them.

> How would you do that with library functions (even allowing for
> overloading)?

This is just a matter of how you define automatic promotions. But I'm
not a huge fan of automatic promotions; it's just not that easy to get
them right (I mean to get the rules right so that they make sense and
don't create more confusion than they help), and the work involved (for
the programmer) is IMO more with automatic promotions (always need to be
on the lookout for the cases where the automatic promotions don't work
as needed) than with manual type casts.

In the case above, if I wanted to assign the integer division result of
y/z to the float x, I'd have to remember to use a temporary intermediate
variable, so that the compiler actually does what I want:

  float x;
  int y, z;

        int temp; // Only needed to "trick" the compiler
        temp = y / z; // into doing what I want.
  x = temp;

I don't like this anymore than I like the C style automatic promotions.
I'm a declared fan of explicit type casts.


> How would the compiler do the promotion here?
>
> assign(&x, div(y, z));

Depending on how the language standard defines them, and the way
assign() is declared. I still fail to see what the difference is between
an operator '=' and a function assign(). (In fact, in C++ there isn't
even any, built-in or library.)


Of course, I agree that there probably are some optimizations that can
be done when the code generation is in charge of everything. But it
seems that so far you couldn't bring a good example where the difference
wasn't in something else. The first examples were about compile-time
evaluations, which are not part of the C standard, but could be part of
a similar language standard. The latter examples were about function
calls where the functions are "black boxes" to the compiler, ignoring
the fact that for /standard/ library functions, the compiler knows
exactly what they do (or are supposed to do).

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Olin Lathrop wrote:

> K+R were in a research setting where they didn't have to care about
> profit or competitive advantage.  They had nothing to loose by
> letting everyone at it,

They were in a commercial venue, porting Unix from PDP-7 to PDP-11. This
is the reason why they created C, as a sort of a portable assembler.
(This wasn't a research project, it was commercial -- they wanted to
sell the PDP-11 :) Wirth created Pascal at the ETH in Zürich; not more
commercial than AT&T, it seems, perhaps less :)

I don't think there's a big difference in balance between research and
commercial compiler writers between C and Pascal. I think it wasn't
until the early 80ies that the first commercial Pascal compilers showed
up (Watcom, Apple, Borland). Until then, it seems, they were all created
by universities. And after then, there were just as many commercial C
compilers.

> Of course there were standards, but companies opening their
> proprietary operating systems and large programs like compilers was
> certainly not the prevailing way things were done.

Right. But IMO this hasn't much to do with C's popularity or Pascal's
lack thereof. I think the main reason is that there was, from the 80ies
on, pretty much /one/ C but many (incompatible) Pascals. A compiler
writer didn't have a clear road to follow for compatibility. The
standard wasn't suitable and not popular anyway, and then there were the
many proprietary and diverging dialects.

>> There is also an ISO standard for the original Pascal that dates back
>> to 1983. But it seems that this standard wasn't usable; for a number
>> of reasons, everybody implemented their own versions.
>
> I'm guessing that didn't work because it was too late.  

You probably didn't read up on the history, and on the standard itself.
C wasn't standardized until later, so 1983 wasn't too late. The thing is
that there doesn't seem to have been a consensus what makes a "good"
Pascal, so there wasn't /a/ Pascal, there were many Pascals -- and all
incompatible with each other. The only consensus, it seems, was that the
standard isn't good enough, so Pascal programmers never seemed to have
cared about standard conformance. Which is different from C; for the
typical C programmer, standard conformance was always an issue. (First
the K+R "standard", then the C89 standard. C99 is here, but not quite
yet. Most compilers don't support it, so the kind of inofficial standard
is still C89.)

> A lot of code existed in each version, so I'm guessing nobody wanted
> to have their code orphaned.  

If this was the case, it was a bad decision, it seems -- rather than
getting together, making some compromise, create a common and usable
standard and live on, they wanted only their proprietary piece and died.
This may be a lesson...

Gerhard

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Gerhard Fiedler wrote:
>  float x;
>  int y, z;
>
> int temp; // Only needed to "trick" the compiler
> temp = y / z; // into doing what I want.
>  x = temp;
>
> I don't like this anymore than I like the C style automatic promotions.

As you said, yucc.  For any of you that might be interested, Pascal solves
this in a nice way by having two divide operators, "/" and "div".  "/"
always produces a floating point result, whether performed on integers or
not.  Div always does a integer divide, can only be performed on integers,
and produces a integer result.  This scheme provides both the necessary
information to the compiler and good readability in the source code.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Tamas Rudnai]

On Wed, Jul 8, 2009 at 2:39 PM, Gerhard Fiedler
<lists@...>wrote:

> Wirth created Pascal at the ETH in Zürich; not more
> commercial than AT&T, it seems, perhaps less :)


the original Pascal was only intended to be able to teach the logic of
structured programming. It is just a coincident that it turned out that the
language was quite friendly so with some improvements it could used for
commercial programming as well. The incompatibility was only coming because
of these error and try efforts: Everyone wanted to make their commercialised
implementation better than the other -- same stuff as what you can see now
with the C compilers for PIC: Each of them differs where they can be, like
pragmas, fuses, types, libraries etc. You need to put some effort but can
still implement your code into another C compiler than it was originally
written to -- same as with Pascal... I cannot see the difference much?

Tamas

>
>
> I don't think there's a big difference in balance between research and
> commercial compiler writers between C and Pascal. I think it wasn't
> until the early 80ies that the first commercial Pascal compilers showed
> up (Watcom, Apple, Borland). Until then, it seems, they were all created
> by universities. And after then, there were just as many commercial C
> compilers.
>
> > Of course there were standards, but companies opening their
> > proprietary operating systems and large programs like compilers was
> > certainly not the prevailing way things were done.
>
> Right. But IMO this hasn't much to do with C's popularity or Pascal's
> lack thereof. I think the main reason is that there was, from the 80ies
> on, pretty much /one/ C but many (incompatible) Pascals. A compiler
> writer didn't have a clear road to follow for compatibility. The
> standard wasn't suitable and not popular anyway, and then there were the
> many proprietary and diverging dialects.
>
> >> There is also an ISO standard for the original Pascal that dates back
> >> to 1983. But it seems that this standard wasn't usable; for a number
> >> of reasons, everybody implemented their own versions.
> >
> > I'm guessing that didn't work because it was too late.
>
> You probably didn't read up on the history, and on the standard itself.
> C wasn't standardized until later, so 1983 wasn't too late. The thing is
> that there doesn't seem to have been a consensus what makes a "good"
> Pascal, so there wasn't /a/ Pascal, there were many Pascals -- and all
> incompatible with each other. The only consensus, it seems, was that the
> standard isn't good enough, so Pascal programmers never seemed to have
> cared about standard conformance. Which is different from C; for the
> typical C programmer, standard conformance was always an issue. (First
> the K+R "standard", then the C89 standard. C99 is here, but not quite
> yet. Most compilers don't support it, so the kind of inofficial standard
> is still C89.)
>
> > A lot of code existed in each version, so I'm guessing nobody wanted
> > to have their code orphaned.
>
> If this was the case, it was a bad decision, it seems -- rather than
> getting together, making some compromise, create a common and usable
> standard and live on, they wanted only their proprietary piece and died.
> This may be a lesson...
>
> Gerhard
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.mcuhobby.com
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[sergio masci-2]

On Wed, 8 Jul 2009, Olin Lathrop wrote:

> Gerhard Fiedler wrote:
> >  float x;
> >  int y, z;
> >
> > int temp; // Only needed to "trick" the compiler
> > temp = y / z; // into doing what I want.
> >  x = temp;
> >
> > I don't like this anymore than I like the C style automatic promotions.
>
> As you said, yucc.  For any of you that might be interested, Pascal solves
> this in a nice way by having two divide operators, "/" and "div".  "/"
> always produces a floating point result, whether performed on integers or
> not.  Div always does a integer divide, can only be performed on integers,
> and produces a integer result.  This scheme provides both the necessary
> information to the compiler and good readability in the source code.

Likewise FYI: XCSB decides on which division operator to use depending on
where the result is to go. So:

        float x
        int y, z

        x = y / z

would use a floating point division because the expected result is a
floating point. If you wanted to use integer division you would write:

        x = (int)(y / z)

This actually tells the compiler that you want to produce an integer as
the result of the division.

Friendly Regards
Sergio Masci
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[sergio masci-2]

On Wed, 8 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
>
> > I chose sin because to a great many people it is a black box which
> > they can relate to rather than some complex function that I'd invent
> > as an example.
> >
> > Yes the compiler writer could allow the programmer to attach a ton of
> > attributes to a library function to help it understand the function
> > better but that's not the point. The point is to make it simpler for
> > a programmer to write good code that is easy to maintain - to allow
> > the compiler to extract the necessary information from the function
> > itself without the programmer needing to add extra attributes - which
> > like comments might actually be at odds with the code and be wrong
> > (yet something else to debug).
>
> I was talking about standard libraries, where the programmer doesn't
> have to attach anything. The difference between libraries in general and
> standard libraries is that the standard libraries must conform to a
> standard to be a standard library, not any more or any less than a
> compiler. Of course such a standard in general doesn't define how it is
> implemented, but it defines what it does.

So you are saying a standard library (I thought you were talking about the
STL as you were also discussing containers at the time) should be
different to a user defined library? I think the users would eat you alive
if you dared create a divide between the standard and user libraries (such
that the user libraries could not optimised to the same high level as the
standard libraries).

>
> > Let's try something a little bit more interesting:
> > [...]
> > main()
> > {
> > ...
> > delete_item(pos, &len, arr);
> > insert_item(pos, val, &len, arr);
> > ...
> > }
> >
> > Now how would you give the compiler enough information in the attributes
> > of the functions to be able to automatically optimise the above into the
> > equivalent of:
> >
> > replace_item(pos, &len, arr);
>
> This function should have been part of the interface in the first place.
> This is the tricky part of defining a good library interface: provide
> the interface that makes sense.

No you've missed my point here. It's not that the function was missing
it's that the programmer didn't use it and the compiler had no way of
knowing that there was a better way to do things - because they were
library functions with a brick wall in the way.

>
> > A far more concrete example would be that of having multitasking built
> > into the language rather than as a bolt-on library. XCSB knows about
> > multitasking and generates optimised code around it. You don't need
> > to generate several stacks and functions that need to be re-enterent
> > just in case they are being used in several tasks. Don't you think
> > that's a benefit?
>
> Of course. C for example lacks any multitasking specification; it wasn't
> relevant at the time the C spec was created, because it was handled by
> the operating system, exclusively.

I think you might want to check that. C was used in multitasking
situations on bare metal (without a cosey OS or even a supervisor) for
some time before the C spec was created. Look at all the apps written for
embedded or process control systems in C. Also OCCAM and ADA supported
multitasking directly.

> Now it's common for applications to
> do multithreading inside the application, and this shows the
> shortcomings of a suitable standardization.
>
> But besides this, I think that what you are talking about is an
> optimization. The compiler should have enough knowledge to be able to do
> it, and it should be specified well enough so that multitasking features
> are specified, but I still fail to see the big difference whether this
> is specified as a standard library or as part of the compiler.

It's to do with giving the compiler more information on which to base its
analysis of the source code. The more information you give it the better
job it can do. This results in a greater ability to catch errors and
generate robust optimised code.

When you write a small fragment of code and you know (for example) that it
only has to count a maximum of say 10 items, you can decide to use an 8
bit wide unsigned integer to do the counting within that small fragment.
The knowledge you have is not actually present within that small fragment
of code and there is no way that the compiler can verify that any changes
you make later on in some other piece of code do not conflict with this
"10 item assumption" for this fragment UNLESS you jump through hoops to
try to tie this "10 item requirement" to this fragment. You should not
need to jump through hoops to do this and the compiler should be able to
take this requirement and propergate it throughout the rest of the
executable that it is building. The function interfaces in libraries act
as brick walls impeading this process.

>
> > I mean the fact that you can get tight efficient multitasking code
> > written in a HLL to work on something as small as a 16F628?
>
> People do it all the time. It is of course a feat to have this built
> into the compiler. The real feat is, however, to design this and
> standardize this in a way that it is efficient and suitable for
> everything from an embedded application running on "bare metal" in a
> 16F628 to an embedded application running on a stripped down Linux in an
> ARM to a desktop application running on Windows XP in a multicore
> processor.
>

I understand that SOME people have had success doing this is assembler for
a small MCU like the 628 but I am not aware of any C / library combination
that is efficient enough to allow you to do any more than flash a few LEDs
on a 628. If you know of any please let me know.

Having a language and compiler that would generate efficient multitasking
code on both a 628 and Windows XP in a multicore processor would be a
feat. But the hardest part (that of getting it to work on a 628) is done!
Surely you can see that doing the same for a system with MUCH better
resources is trivial in comparison. Even if the XCSB compiler were to
generate simple intermediate C source code for the XP system the fact is
that you could have the same XCSB code running on both the 628 and XP (if
we ignore the hardware specific registers).

>
> > This was a trivial example but consider a much more real case where
> > the above code would actually exist in a library as part of the
> > 'init' sequence of a module. Ideally the programmer would be
> > insulated from having to build large complex static tables within
> > his/her main line. This should all be taken care of by the library
> > writer / maintainer.
> >
> > You must have come across some horrible libraries yourself where
> > several things need to be declared as "#defines" before the
> > corresponding header of the library is included into your main line
> > for the sake of efficiency.
>
> Of course. But this is just a side effect of a limitation of C, not of
> the fact that this was in a library rather than in the compiler. Much of
> this ugly preprocessor code you're referring to is due to the fact that
> the C language doesn't specify much (if any?) compile-time evaluations.
> To do this, people have to resort to the preprocessor. Complex
> compile-time evaluations could/should part of a good language
> definition; it would help a lot, especially on small systems. But IMO
> this hasn't much to do with whether these calculations are defined in
> library code or in something that's supported by the compiler directly.

This discussion certainly is helping me think more deeply about things I
have taken for granted for a long time now.

For one thing I wonder just how popular C would have been without the
conditional compilation capability provided by the C pre-processor.
Allowing one set of source files to be compiled for different targets.
There again the interface between the pre-processor and the compiler
proper is another brick wall.

>
>
> > If you replaced the operators '=' and '*' with 'assign' and 'mult' such
> > that the above was re-written as
> >
> > assign(&x, mult(j, 2));
> >
> > how would you give the compiler enough information on the above
> > functions to be able to do the same level of optimisation as before?
>
> If the semantics of assign and mult are clearly defined by a standard,
> it could do the same optimizations.

Yes it could but again it would be down to the compiler to generate the
appropriote optimised code and not just generate code to handle the
calling protocol of library functions.

Can you not see that in adding more and more attributes to the library all
you are really doing is trying to push the libraries into the compiler?

>
> > And forgetting about optimisation completely, what about promoting
> > integers to floats?
> >
> > e.g.
> > float x;
> > int y, z;
> >
> > x = y / z;
> >
> > here a decent language / compiler could see that the result result needs
> > to be a float and promot y and z to floats and perform a floating point
> > division.
>
> This may be what the programmer wants, or not. The compiler doesn't know
> whether I want y/z be an integer division or a float division or a
> double division. Chances are that if I had written this, it wouldn't be
> what I want. But I don't write such code; I tend to use explicit casts
> to make sure both the compiler and the human reader of the code know
> what the code is supposed to do. If I could, I'd disable automatic
> promotions in C and C++, so that I don't forget any explicit cast. Where
> compilers have warnings for this, I enable them.

Yes but we are talking about what comes naturaly not what comes of years
of discipline of using a particular language. A great many pleople get
caught with this type of integer division in C. It takes years for many
people to reliably use integer division (without the odd slip). The
compiler is there to help you. The computer is there to do what you want.

You souldn't need to do what does not come naturaly. That's error prone.

>
> > How would you do that with library functions (even allowing for
> > overloading)?
>
> This is just a matter of how you define automatic promotions. But I'm
> not a huge fan of automatic promotions; it's just not that easy to get
> them right (I mean to get the rules right so that they make sense and
> don't create more confusion than they help), and the work involved (for
> the programmer) is IMO more with automatic promotions (always need to be
> on the lookout for the cases where the automatic promotions don't work
> as needed) than with manual type casts.
>
> In the case above, if I wanted to assign the integer division result of
> y/z to the float x, I'd have to remember to use a temporary intermediate
> variable, so that the compiler actually does what I want:
>
>   float x;
>   int y, z;
>
> int temp; // Only needed to "trick" the compiler
> temp = y / z; // into doing what I want.
>   x = temp;
>
> I don't like this anymore than I like the C style automatic promotions.
> I'm a declared fan of explicit type casts.
>

In XCSB the compiler says "Ah, you want to assign the result to a floating
point variable therefor I wont just discard the remainder I'll do the calc
as a float". In XCSB if you wanted to do an integer division even though
the result should be a float you would do

        x = (int)(y / z)

>
> > How would the compiler do the promotion here?
> >
> > assign(&x, div(y, z));
>
> Depending on how the language standard defines them, and the way
> assign() is declared. I still fail to see what the difference is between
> an operator '=' and a function assign(). (In fact, in C++ there isn't
> even any, built-in or library.)
>
>
> Of course, I agree that there probably are some optimizations that can
> be done when the code generation is in charge of everything. But it
> seems that so far you couldn't bring a good example where the difference
> wasn't in something else. The first examples were about compile-time
> evaluations, which are not part of the C standard, but could be part of
> a similar language standard. The latter examples were about function
> calls where the functions are "black boxes" to the compiler, ignoring
> the fact that for /standard/ library functions, the compiler knows
> exactly what they do (or are supposed to do).

There are many aspects to this compiler verses libraries debate. The
biggest problem is the brick wall between the source code the compiler is
trying to analyse and the library. "Compile-time evaluations", "function
calls as 'black boxes'" these are dependent on the "brick wall". This is
what I am trying to describe. You say that I am:

        "ignoring the fact that for /standard/ library functions, the
        compiler knows exactly what they do (or are supposed to do)."

I'm not. The fact is the compiler does not know. It has an interface
definition for each funtion in the form of a function prototype in a
header file somewhere. But that's about it. The compiler is only given
enough info on the function to allow it to comply with the protocol for
invoking the function. You can extend the compiler so that function
prototypes can have special attributes (like GCC) such that you tell the
compiler "hey, this function doesn't use any statics, or global variables,
it only modifies its own locals and its result is totally dependent on the
input value". Ok so you can do that, but what else can you do? Actually
very little. GCC only has a handfull of such attributes that you can use
for a function.

If you're going to implement something that would allow the "standard"
library to be used in the same way as a more intelligent compiler for a
much more sophisticated language than C for C then you are going to have
to do a hell of a lot of work. It's not something you could easily tack
onto C.

Friendly Regards
Sergio Masci
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[William "Chops" Westfield]

On Jul 8, 2009, at 6:39 AM, Gerhard Fiedler wrote:
>> K+R were in a research setting where they didn't have to care about  
>> profit or competitive advantage.  They had nothing to loose by  
>> letting everyone at it,
>
> They were in a commercial venue, porting Unix from PDP-7 to PDP-11.  
> This is the reason why they created C, as a sort of a portable  
> assembler. (This wasn't a research project, it was commercial --  
> they wanted to sell the PDP-11 :)

K&R were at Bell Labs, weren't they?   While Bell Labs wasn't quite so  
bad as (say) Xerox PARC, they were pretty far away from being  
"commercial", especially in those days!  (Look at how long it took  
before Unix became a commercial offering.)

And "AT&T wanted to sell [DEC] PDP11s"??  Huh??


> Wirth created Pascal at the ETH in Zürich; not more commercial than  
> AT&T, it seems, perhaps less :)

Ah, you know those university profs.  Their "product" is publication  
("publish or perish"); especially nice because commercial viability is  
less of an issue...  :-)

BillW


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

sergio masci wrote:

>> I was talking about standard libraries, where the programmer doesn't
>> have to attach anything. The difference between libraries in general
>> and standard libraries is that the standard libraries must conform
>> to a standard to be a standard library, not any more or any less
>> than a compiler. Of course such a standard in general doesn't define
>> how it is implemented, but it defines what it does.
>
> So you are saying a standard library (I thought you were talking
> about the STL as you were also discussing containers at the time)
> should be different to a user defined library? I think the users
> would eat you alive if you dared create a divide between the standard
> and user libraries (such that the user libraries could not optimised
> to the same high level as the standard libraries).

You were talking about intent. For a normal library, the compiler
doesn't know about intent. For a library with a standardized interface
(for example, the C++ STL) the compiler does know about intent.

>> This function should have been part of the interface in the first
>> place. This is the tricky part of defining a good library interface:
>> provide the interface that makes sense.
>
> No you've missed my point here. It's not that the function was
> missing it's that the programmer didn't use it and the compiler had
> no way of knowing that there was a better way to do things - because
> they were library functions with a brick wall in the way.

I'm not sure whether you're not missing my point. If all three functions
are defined as functions of a standard library (including their
semantics), the compiler "knows" about them and what they do. And if
replace is a suitable (and more efficient) substitution for delete
followed by an insert, it may substitute it.


>> Of course. C for example lacks any multitasking specification; it
>> wasn't relevant at the time the C spec was created, because it was
>> handled by the operating system, exclusively.
>
> I think you might want to check that. C was used in multitasking
> situations on bare metal (without a cosey OS or even a supervisor)
> for some time before the C spec was created. Look at all the apps
> written for embedded or process control systems in C. Also OCCAM and
> ADA supported multitasking directly.

I was talking about C, not about other languages. And besides sequence
points and some additional guarantees for volatile variables, you won't
find many help in the C standard for multitasking, especially when
multiple cores are involved.

It has been done, but one needs to know what one does when doing so, and
it's not necessarily portable. For example, the standard doesn't
prohibit RMW problems that occur because the compiler would load two
16bit variables in a 32bit register, work on one, but write both back
(while potentially the other one has been overwritten in memory by
another thread running on another core). There are a number of other
such problems that are not addressed by the standard.


> Having a language and compiler that would generate efficient
> multitasking code on both a 628 and Windows XP in a multicore
> processor would be a feat. But the hardest part (that of getting it
> to work on a 628) is done! Surely you can see that doing the same for
> a system with MUCH better resources is trivial in comparison.

No, I can't see that. Portable, safe and efficient multitasking on a
modern multicore system is in no way trivial. It is IMO more complex
than multitasking on a 628, by a few magnitudes.


> This discussion certainly is helping me think more deeply about things
> I have taken for granted for a long time now.
>
> For one thing I wonder just how popular C would have been without the
> conditional compilation capability provided by the C pre-processor.
> Allowing one set of source files to be compiled for different
> targets. There again the interface between the pre-processor and the
> compiler proper is another brick wall.

I think they serve different purposes, but the C preprocessor has been
used to address some of the C compiler's shortcomings. I don't think the
separation (or "brick wall") between the two is really a problem. I
think C would be a "better C" (especially for small micros) if it had a
compile-time evaluation capability. And Pascal would have been a better
Pascal if it came with a preprocessor.

(The latter is a bit easier to address if you're not using an integrated
IDE like Turbo Pascal, because then you can add a preprocessor step to
your build step. But then again, everybody would use a different
preprocessor and the code wouldn't be portable again :)


>> If the semantics of assign and mult are clearly defined by a standard,
>> it could do the same optimizations.
>
> Yes it could but again it would be down to the compiler to generate the
> appropriote optimised code and not just generate code to handle the
> calling protocol of library functions.

Right. But sometimes the compiler does generate the code for the library
functions (or at least it's under control of the programmer whether it
does or not), so I'm not seeing the difference.

Of course, the traditional C concept of separate translation units is
just the way you're describing. But this doesn't have to be so, and
supposedly e.g. HiTech's OCG or Microsoft's link-time code generation
are attempts to improve on this.

I think it may be (trying to be careful here :) that you're focusing too
much on some arbitrary limitations of C. It's probably unavoidable, but
many of C's limitations are arbitrary (that is, mostly historical) and
not necessary.

> Can you not see that in adding more and more attributes to the library
> all you are really doing is trying to push the libraries into the
> compiler?

I never thought or wrote about adding attributes to the library. I just
wasn't thinking in terms of separate translation units, I was thinking
of /standard/ libraries (that is, libraries with a clearly defined
interface) and I was thinking about libraries that come in source code.


> Yes but we are talking about what comes naturaly not what comes of
> years of discipline of using a particular language. A great many
> pleople get caught with this type of integer division in C. It takes
> years for many people to reliably use integer division (without the
> odd slip). The compiler is there to help you. The computer is there
> to do what you want.

I think when it comes to type conversion, it should always be explicit.
This is especially important on small systems with limited resources. It
is my experience that more often than not, if you don't do it
explicitly, you have to comment it one way or another. I prefer not to
comment it, but to do it explicitly in the code.

> In XCSB the compiler says "Ah, you want to assign the result to a
> floating point variable therefor I wont just discard the remainder
> I'll do the calc as a float". In XCSB if you wanted to do an integer
> division even though the result should be a float you would do
>
> x = (int)(y / z)

IMO, as I just said, I don't like automatic conversions. I don't think
the compiler has a good chance to figure out what I want. Pinning the
operation on the result is just as dangerous as pinning it on the
operands. I may divide one 32bit int by another 32bit int and put the
result into an 8bit int. I don't want the division to be an 8bit int
division. I may divide an 8bit int by another 8bit int and put the
result into a 32bit int, and I don't want the division to be a 32bit int
division. And so on... I think such type conversions should be explicit.


> I'm not. The fact is the compiler does not know. It has an interface
> definition for each funtion in the form of a function prototype in a
> header file somewhere. But that's about it.

I think this may be the one misunderstanding that we have. I'm thinking
of libraries that are available in source code with a standardized and
clearly defined interface, like most (if not all) C++ standard
libraries.

Also, even though the comparison between XSCB (did I get it right this
time? :) and C is kind of underlying here, I don't think that C's
arbitrary limitations are relevant to this discussion /in principle/.

I know that for everyday work, you don't compile the standard library;
you use pre-compiled "brick walled" object code libraries. (I don't know
how much e.g. Microsoft's link-time code generation does bring here;
supposedly, since it's at link time, it would also optimize library code
that's pre-compiled.) But nothing would prevent the programmer from
running the compiler on the whole source code.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

William "Chops" Westfield wrote:

>>> K+R were in a research setting where they didn't have to care about
>>> profit or competitive advantage.  They had nothing to loose by
>>> letting everyone at it,
>>
>> They were in a commercial venue, porting Unix from PDP-7 to PDP-11.
>> This is the reason why they created C, as a sort of a portable
>> assembler. (This wasn't a research project, it was commercial --
>> they wanted to sell the PDP-11 :)
>
> K&R were at Bell Labs, weren't they? While Bell Labs wasn't quite so
> bad as (say) Xerox PARC, they were pretty far away from being
> "commercial", especially in those days! (Look at how long it took
> before Unix became a commercial offering.)

But didn't AT&T (owner of Bell Labs) sell Unix licenses? Not to the
general public, but still sell them?

> And "AT&T wanted to sell [DEC] PDP11s"??  Huh??

Right... got that mixed up. They wanted to sell Unix for those PDP-11s
-- or not?


>> Wirth created Pascal at the ETH in Zürich; not more commercial than  
>> AT&T, it seems, perhaps less :)
>
> Ah, you know those university profs.  Their "product" is publication
> ("publish or perish"); especially nice because commercial viability
> is less of an issue...  :-)

Exactly. They don't have to worry about commercial success, so they
could do it right. Which they apparently didn't, in this case :)

Gerhard

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Tamas Rudnai wrote:

> the original Pascal was only intended to be able to teach the logic of
> structured programming. It is just a coincident that it turned out
> that the language was quite friendly so with some improvements it
> could used for commercial programming as well. The incompatibility
> was only coming because of these error and try efforts: Everyone
> wanted to make their commercialised implementation better than the
> other -- same stuff as what you can see now with the C compilers for
> PIC: Each of them differs where they can be, like pragmas, fuses,
> types, libraries etc. You need to put some effort but can still
> implement your code into another C compiler than it was originally
> written to -- same as with Pascal... I cannot see the difference
> much?

You need to look at the bigger picture. C didn't become popular because
of PICs. There are many C programs that compile (and run) on any
standard-compliant compiler, on quite different platforms. While
platform differences sometimes need some conditional parts in the code,
it is possible (and common) to write portable C code that compiles on
gcc, VC++ (in C mode) and a number of other compilers and runs on Linux,
Unix, Solaris, Windows, Mac OSX and others (and depending on the amount
of resources and OS support required for the specific program, also on a
bare-metal PIC).

Also, while with Pascal you may be able to port your code from one
Pascal to the other, from one platform to the other, but then you have
two (or more) code bases. With C, even if you have to make adjustments
for a specific platform, you usually integrate them into the code -- and
end up with code that compiles and works on the previously supported
platforms and on the new platform.

Try that with (any) Pascal. The lack of standardization (and of a
standard preprocessor, for the sometimes necessary platform adjustments)
makes this pretty much impossible.

(I'm not trying to say that "C is better than Pascal" :)

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Olin Lathrop]

Gerhard Fiedler wrote:
> You were talking about intent. For a normal library, the compiler
> doesn't know about intent. For a library with a standardized interface
> (for example, the C++ STL) the compiler does know about intent.

I think you guys are talking past each other.  I think what Gerhard is
trying to say, but not doing a good job of it, is that he wants things that
look like library calls but that are really intrinsic functions that the
compiler understands natively.  The compiler would completely know the
intent of these functions and would be free to write in line code, call a
runtime library function, or optimize the "call" in any other way it sees
fit.  It could even eliminate it altogether if it could somehow detect that
results are never used, for example.

I think Sergio is saying is that this would be a great deal of work to add
that kind of knowledge into the compiler about common functions.

There have been cases where this was done, but naturally they are scarce
given the considerable compiler development required to support them.
First, most languages already have a set of intrinsic functions for basic
low level operations.  Bit shifts in Pascal are done that way, for example.
The LSHFT and RSHFT functions are known to the compiler and don't cause
library calls in most implementations.  My Pascal front end detects them and
a number of other intrinsic functions and writes out their resulting code.
LSHFT and RSHFT result in the << and >> operators if the result is written
in C.

Another case I remember is Silicon Graphics built in a few of the key
graphics calls of GL into their compiler.  Graphics functions are often
speed-critical since they can easily be executed millions of times while a
user is waiting for instant response.  A few of the GL calls were mapped
directly to I/O operations on their proprietary hardware and could be just a
few instructions.  A true call would have added at least as much overhead as
the target instructions, and would have prevented the compiler from doing
any optimization.

All in all I think intrinsic functions should be limited, especially when
common names are chosen.  It's dangerous to have a lot of reserved names in
a namespace the user can also create symbols in.  Of course you don't want
to have keyword bloat either, and the inline function syntax is convenient
for expressing a lot of things.  So as with everything, its a tradeoff.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
[phone].  Gold level PIC consultants since 2000.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist