Re using BREAK in 'C'

[sergio masci-2]

On Sat, 4 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
>
> > On Thu, 2 Jul 2009, Tamas Rudnai wrote:
> >> I think it is not a win or loose conversation. I love these
> >> conversations too as many times some very important thoughts pulled
> >> out of someones head that would never mentioned otherwise.
> >>
> >
> > Actually I agree with Tamas.
> >
> > I find that trying to discuss languages with most people these days
> > tends to boil down to: use C, use C++ or use Java. Not very
> > productive if you're trying to do something better.
>
> 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.

You forgot the "conformance" aspect. Ada is a registered trademark of the
US DoD. To write an Ada compiler, the vendor needs (needed?) to jump
through DoD hoops. The compiler needed to be certified and anyone using
the compiler could not do DoD work if the certification had expired (they
had to be recertified every year) without special DoD excemption.

With all this BS going on, it's no wonder Ada never really took off.

>
> > Remember, the point of a programming language is to allow the user to
> > describe the problem so that the compiler can generate the best code
> > to solve that problem.
>
> One thing that's missing in this affirmation is that it's not typically
> about "the compiler can generate the best code". Typically it's foremost
> about describing the problem in an efficient way -- for the programmer.
> The compiler doesn't have to produce the best code possible; it has to
> produce code that's good enough. But it has to make the programmer's job
> easy; this is its main job.
>

Yes I can see where you are comming from. So what would you say to a
programmer who points at your generated code and laughing says "I could
have done that in half the number of machine code instructions" using C.
If your C "successor" is going to stand any chance of competeing with C,
it's got to generate code that's at least on a par with it.

> It seems a certain part of the engineering population thinks that ladder
> logic is an adequate way to describe their control problems, yet ladder
> logic compilers are definitely unpopular with the micro crowd. There
> seem to be groups that have different views of what is the easiest way
> to describe a problem.

Yes but most people that like ladder logic are not expert programmers.

>
> Another thing that's IMO missing in the affirmation above is that it's
> not about "the" problem, it's about "a relevant subset of all
> engineering problems". And here is where the "glorified assembler" (and
> assembler) comes in, with the flexibility to address problems in not yet
> thought-of domains.

But most problems can be broken down into much smaller well defined
processes such as search, sort, append, remove etc. which a language
should be able to apply to basic data types such as lists, sets, heaps,
arrays, strings etc. For any really complex not yet thought-of domains we
have libraries. I am so fed up with the notion that we need libraries for
everything, that the language needs to be so rediculasly simply as to not
be able to understand types such as lists, strings, dynamic array etc.
when these types are so common and well understood.

>
>
> > It is not to micro manage the generation of an executable such that
> > the compiler becomes nothing more than a glorified assembler.
>
> Hm... With "nothing more than a [...] assembler" you're probably
> correct. OTOH, I don't know of any language in widespread use that is
> "nothing more". (We could probably disagree on what "glorified" means :)
>
> But if you substitute "nothing more" with "not much more", things are
> not so simple anymore. It is a tricky balance between adaptable and
> standardized, lightweight and powerful, flexible and supporting, almost
> requiring, good practices, universal and highly optimized, allowing
> solutions adequate for every domain and including yet unknown domains,
> ...
>
>
> One thing I wonder is why we haven't seen a programming language on
> silicon. Not a Basic interpreter in firmware, but something more
> substantial and efficient, along the lines of the Java micros (that
> never seem to take off). Is this because it produces faster code with
> the same amount of silicon when a compiler optimizes assembly than when
> microcode executes high-level constructs directly?

I think if you look at a high level language like Java or even the
executable produced by something like a C++ compiler, you will find that
the native machine code being executed is not the problem - the problem is
all the dynamic memory management that is going on. Objects being created
and destroyed just so that trivial operations can be performed without
impacting on other objects.

Personally I think if you really want to optimise a processor to execute
high level code more efficiently then it needs an evaluation stack (kind
of like FORTH) where you can say in one instruction "load the stack with
this sequence and evaluate it" then let the CPU orchestrate the memory
accesses to best optimise fetching of values. You could even help it by
trying to organise variables so that they are near each other in memory.
Two stackes would probably be best, one for manipulating data and one for
addresses. Offten you don't need to recaclulate an address if you can make
sure a side effect of the calculation is to put it somewhere where it can
be used again with minimal effort (e.g. do the calculation in an index
register and use a different index register for the next address if
possible).

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

[Gerhard Fiedler]

sergio masci wrote:

> You forgot the "conformance" aspect. Ada is a registered trademark of
> the US DoD.

Yup, didn't think of that. Definitely a killer.


> Yes I can see where you are comming from. So what would you say to a
> programmer who points at your generated code and laughing says "I
> could have done that in half the number of machine code instructions"
> using C. If your C "successor" is going to stand any chance of
> competeing with C, it's got to generate code that's at least on a par
> with it.

If it's competing on its turf, then yes. If I can say "I have developed
the application in 10% of the time it would have taken to develop it in
C", then it depends. That's probably the reason why C (and assembly) is
not that popular with bigger systems, notwithstanding its popularity
with smaller systems.


>> It seems a certain part of the engineering population thinks that
>> ladder logic is an adequate way to describe their control problems,
>> yet ladder logic compilers are definitely unpopular with the micro
>> crowd. There seem to be groups that have different views of what is
>> the easiest way to describe a problem.
>
> Yes but most people that like ladder logic are not expert programmers.

Most people, and even most programmers, are not expert programmers (by
definition... :)

There is a place for languages that can be used by domain experts
efficiently, so that they don't need expert programmers to solve their
problems. What we do when we solve a problem with a microcontroller and
C (or assembly, or Pascal, or even XSBC :) is often a "hack", in the
absence of a better solution; the real solution would be something that
allows the domain expert to do it herself.


> But most problems can be broken down into much smaller well defined
> processes such as search, sort, append, remove etc. which a language
> should be able to apply to basic data types such as lists, sets,
> heaps, arrays, strings etc. For any really complex not yet thought-of
> domains we have libraries. I am so fed up with the notion that we
> need libraries for everything, that the language needs to be so
> rediculasly simply as to not be able to understand types such as
> lists, strings, dynamic array etc. when these types are so common and
> well understood.

I for one never understood this "war" between language and libraries. I
don't really care that much whether C++ has a decent array type built
into the language or whether there are the C-style arrays for backwards
compatibility and as a decent solution there is std::vector from the
standard library. The standard libraries are, at least with C and C++,
part of the language specification.

Then there are those cases where I still code my own containers, because
for the one or other requirement, the standard containers don't fit my
bill. Probably no language built-in container can do it all; there too
many different sets of requirements with different solutions.

You probably have a point with strings (in C and C++), but there is the
dreaded backwards compatibility that sooner or later hits everything
that is used for long enough, and so C is pretty much stuck with the
half-assed string implementation it has. In C++ there is std::string,
which works for many cases well enough (and again I don't really care
that much that this is from a library).


> I think if you look at a high level language like Java or even the
> executable produced by something like a C++ compiler, you will find
> that the native machine code being executed is not the problem - the
> problem is all the dynamic memory management that is going on.
> Objects being created and destroyed just so that trivial operations
> can be performed without impacting on other objects.

You're probably right. Heap management and garbage collection, pointer
and reference mechanics, support for polymorphism and virtual functions
-- all in microcode, directly executed, wouldn't that be nice? But by
judging from the

> Personally I think if you really want to optimise a processor to
> execute high level code more efficiently then it needs an evaluation
> stack (kind of like FORTH) [...]

FORTH again... shouldn't it have had more success? :)

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:
>> Personally I think if you really want to optimise a processor to
>> execute high level code more efficiently then it needs an evaluation
>> stack (kind of like FORTH) [...]
>
> FORTH again... shouldn't it have had more success? :)

It had its chance and didn't emerge as a winner for good reason I think.
Back in the early 1980s I thought Forth might be a reasonable solution for
field or customer programmability in some embedded systems.  I even wrote a
few Forth interpreters, one on a general purpose computer for testing and
investigating concepts, and one in a display controller box.  Forth in the
box did exactly what it was intended to to.  It took remarkably little
memory to hold programs for doing math on coordinates, dealing with input
devices, etc, and the speed was adequate enough.

Then I tried to write some more complex programs.  I got them to work and
they worked well, were fast enough, and took little memory, but were a real
pain to write.  It was far more difficult to write good Forth programs than
I had imagined.  The company finally decided, and I agreed, that Forth was
just too difficult even for expert programmers, that making it available in
the product would cost way more in support than any additional revenue
gained by having user programming capability.

One place Forth-like concepts survive today is in PostScript.  I think that
works because all the benefits of Forth are still there, but humans don't
write PostScript.  Forth is actually not that hard a language to compile to,
especially when you're not trying to do arbitrary computations and are just
describing the layout and other specifics of a document.

I did manually write some PostScript once to support a reasonably compact
image file format in EPS (encapsulated PostScript).  Most of the image file
was compressed data for the PostScript program.  The program would maximally
scale and center the image on the page and decompress and print it.  Once
again, that relatively simple program took much longer to write than it
would have in a more traditional language.  It did work very nicely though.
Our EPS image files were not much bigger than ordinary image files, and a
lot smaller than everyone else's EPS image files.  Apparently nobody else
back then thought of using the programmability of PostScript to decompress
image data stored in the same file.


********************************************************************
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]

Gerhard Fiedler wrote:
> This seems to assume that a constant remains constant, which in the
> above isn't the case. He didn't try to access globConst under that name,
> but if the "absolute" directive does what I think it does, its value
> will have changed after the last cited line above.

I don't know what "absolute" is supposed to do, but V3 looks like it's being
defined as a variable and only initialized with the contant value, which is
very different from being a constant such as globConst.

> And the 'real' constants don't seem to have a type, similar to
> the preprocessor #defines in C. Not good either; in a strongly typed
> language, constants should also have a type. Well... nothing's perfect
> :)

I don't know the definition of his language, but in my Pascal CONSTs
certainly have a type.  They have whatever type the constant expression
resolves to.  For example:

const
  a = 'z';
  b = 27;
  c = 3.14;

A will have a type of character, B of integer, and C of floating point.  The
exact format or size of integer and floating point doesn't matter since they
are symbolic constants only and have no inherent realization.  The compiler
can of course create literals for them when needed, but there is no
guarantee that the same memory location will be used for the literal each
time.  The constant value could even be encoded in the immediate value of a
instruction.


********************************************************************
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]

sergio masci wrote:
>> Even if you take this as a excuse for why C was so poorly designed, it
>> still doesn't excuse its widespread use today.  C got popular because
>> it tagged along with Unix and for other marketing reasons like that
>> compilers were available cheaply or freely.
>
> Don't be so dismissive of that tiny little word "free". It tends to be a
> VERY powerful incentive.

I wasn't being dismissive about it and completely agree.

> Ok so rather than simply write another C compiler I took the plunge and
> tried to do something better. How far did this actually get me with you
> an affirmed C detractor. In another post (same thread) you actually
> mention that although XCSB is purportedly not a toy and it is not C you
> haven't tried it. I've tried on various occations to get feedback from
> you (through this list) about what features you would like to see in a
> language but all I've been able to glean is that you'd like very strong
> type checking and the language should really be PASCAL.

I never said the ideal language is Pascal, only that Pascal did get a lot of
things right and I usually use it as a counter-example to C because I know
it pretty well and I have my own version of it.

There are several reasons I haven't tried XCSB.  First no customer has
demanded it, while they have demanded HiTech C and Microchip C18
occasionally.  As a result I have both of them.  Second, no matter how great
a job you do, I'm nervous about anything not from Microchip.  If Microchip
had a compiler for a decent language, I might actually try it, especially if
it didn't do some of the brain dead things C18 does (really stupid stack and
calling conventions).  Third, while I'm not stuck on Pascal, Basic is a real
turn off.  Whether deserved or not, there is a certain perception about it.
Even when customers don't care much what language I use, I don't want to
have the conversation of having to defend the use of Basic.  You would have
been better off calling it something else even if the syntax was heavily
based on Basic.

So where does that leave people who want to innovate and provide a better
language?  Unfortunately in today's world of microcontrollers I think a new
language can only come about one of two ways.  First a company like
Microchip supports it as part of their development suite.  Second anyone
else has to provide it for free so some people who are less in a position
like I am can experiment with it and make it gain some ground.  If it does
and the hardware vendor picks it up, guys like me can finally get to use it.
For my purposes a standard is not that big of a deal since I'm not too
concerned about porting code between PICs and other microcontrollers.
Eventually for general purpose wide acceptance a standard is important
though.

I think if you want to see XCSB take off, you need to get Microchip
interested and have it become theirs with you somehow getting paid off in
the process.  Unfortunately I think that will be a hard sell because
Microchip probably peceives little demand for something better than C.
Hence point that started all this.  It will take a lot of users bitching and
moaning about C before the likes of Microchip will pay any attention and try
to provide something better.  And that can't happen until people widely
agree that C sucks.

> Yes there are things I really hate about C but I really don't want to be
> tied into just implementing a PASCAL compiler - I want to do better.
>
> I'll make you an offer, if you want to produce a free PASCAL compiler
> for the 16 series, I'll let you use my XCASM assembler as a back end
> free of charge provieded it is tied to the compiler so that it can't be
> used as a standalone tool.

Creating a new language for embedded programming, but also useful for
general programming, is actually something on my list of fun things to do.
There are lots of other things on that list (like making a flat sheet of
foam core fly, or at least glide in a controlled way), so my bandwidth for
that is extremely limited.  All I've done so far is jot down a few notes on
syntax and constructs.

What does the interface to the back end of your compiler look like?  What
language is it written in?  What output files does it produce?  Does it
create debug records compatible with MPLAB so that you can do source level
debugging in MPLAB?

I already have the front end of a Pascal compiler since that's how my source
to source translator works.  The front end reads the input source and builds
in-memory structures that define the program in a language-independent way.
The front end then exits and the back end runs to write out the program
definition in whatever output language that back end supports.  SST has
multiple front and back ends, and they can be independently chosen.  In
theory a back end could be created that drives your PIC code generator, but
I'd need to know a lot more about it before getting any idea how much work
that would be.  I just checked, and the C back end of SST is about 8500
lines of code, for example.

> I agree that the resulting code would not have been less efficient but I
> disagree that "the compiler would not have been much harder to write".
> The early C compilers didn't even deal with function prototypes. A lot
> of time was wasted actually tracking down bugs that were the result of
> passing the wrong type of parameter to a function.

I just checked, and the Pascal front end to SST is 7500 lines of code plus
another 750 line syntax defintion file.  Together these not only define the
syntax, parse it, and translate the code to language-independent data
structures, but also perform all the type checking.  For a competent
software engineer setting out to write a whole new program on the scope of a
compiler, I think less than 10000 lines qualifies as "not hard".


********************************************************************
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

[sergio masci-2]

On Sun, 5 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
>
> > You forgot the "conformance" aspect. Ada is a registered trademark of
> > the US DoD.
>
> Yup, didn't think of that. Definitely a killer.
>
>
> > Yes I can see where you are comming from. So what would you say to a
> > programmer who points at your generated code and laughing says "I
> > could have done that in half the number of machine code instructions"
> > using C. If your C "successor" is going to stand any chance of
> > competeing with C, it's got to generate code that's at least on a par
> > with it.
>
> If it's competing on its turf, then yes. If I can say "I have developed
> the application in 10% of the time it would have taken to develop it in
> C", then it depends. That's probably the reason why C (and assembly) is
> not that popular with bigger systems, notwithstanding its popularity
> with smaller systems.
>

Yes but the problem is: are you prepared to take the risk and try a new
programming language just to discover its strengths and weaknesses, to see
it really will save you a great deal of time in both development and
maintinance? And if you are, is your boss?

It's all well and good reading about a language or paradigm that will save
you tons of money and time but having read all these over enthusiastic
claims in the past and found them to be false (if not down right lies),
you tend to treat new claims (that you "hear" about) with a good deal of
sceptisism.

>
> >> It seems a certain part of the engineering population thinks that
> >> ladder logic is an adequate way to describe their control problems,
> >> yet ladder logic compilers are definitely unpopular with the micro
> >> crowd. There seem to be groups that have different views of what is
> >> the easiest way to describe a problem.
> >
> > Yes but most people that like ladder logic are not expert programmers.
>
> Most people, and even most programmers, are not expert programmers (by
> definition... :)

Ok, ok, back to the 99% :-)

Let me change that then to: most people that make a living as a
professional programmer.

>
> There is a place for languages that can be used by domain experts
> efficiently, so that they don't need expert programmers to solve their
> problems. What we do when we solve a problem with a microcontroller and
> C (or assembly, or Pascal, or even XSBC :) is often a "hack", in the
> absence of a better solution; the real solution would be something that
> allows the domain expert to do it herself.
>

I agree which is why I developed the meta CASE tool IPAD-Pro with which
the domain expert together with an expert programmer put together a system
whereby the domain expert can draw a diagram of his/her requirements
in a way that is natural to their domain. The tool then generates code
according to the diagram. It even lets code be simulated on the diagram so
that the diagram, code and requirements can be debugged.

BTW I guess by XSBC you actually mean XCSB :-)

>
> > But most problems can be broken down into much smaller well defined
> > processes such as search, sort, append, remove etc. which a language
> > should be able to apply to basic data types such as lists, sets,
> > heaps, arrays, strings etc. For any really complex not yet thought-of
> > domains we have libraries. I am so fed up with the notion that we
> > need libraries for everything, that the language needs to be so
> > rediculasly simply as to not be able to understand types such as
> > lists, strings, dynamic array etc. when these types are so common and
> > well understood.
>
> I for one never understood this "war" between language and libraries. I
> don't really care that much whether C++ has a decent array type built
> into the language or whether there are the C-style arrays for backwards
> compatibility and as a decent solution there is std::vector from the
> standard library. The standard libraries are, at least with C and C++,
> part of the language specification.
>
> Then there are those cases where I still code my own containers, because
> for the one or other requirement, the standard containers don't fit my
> bill. Probably no language built-in container can do it all; there too
> many different sets of requirements with different solutions.
>
> You probably have a point with strings (in C and C++), but there is the
> dreaded backwards compatibility that sooner or later hits everything
> that is used for long enough, and so C is pretty much stuck with the
> half-assed string implementation it has. In C++ there is std::string,
> which works for many cases well enough (and again I don't really care
> that much that this is from a library).
>

Yes this point seems to elude most programmers.

Think of it like this: when you have a sequence of language keywords the
compiler is able to analyse the sequence in order to try to look for the
"meaning" of the sequence rather than just the statements that the
sequence is made of.

e.g.
this is a loop

        for (j=0; j<10; j++)
        { arr[j] = 0;
        }

here the compiler can optimise the loop in all kinds of ways.
* It knows that j is not modified within the loop
* it knows that the loop is to be repeated 10 times
* it knows that each item in the array is referenced simply relative to j
* it knows that each item of the array is set to a value that is not
  dependent on the order in which the array is processed
* it can also scan ahead of the loop to see if subsequent statements are
  dependent on the value of j once the loop exits

The compiler can actually change this loop to the more optimal form

        for (j=9; j!=0; j--)
        { arr[j] = 0;
        }

which in itself could be used to generate a much more optimised executable
depending on the target CPU (think of Z80 or x86 with native load and
repeat). BTW this is one type of optimisation that XCSB does.


Now if we introduce a function the above optimisations break
e.g.
        for (j=0; j<10; j++)
        { arr[j] = sin(j);
        }

This is because the compiler doesn't really know anything about the
function. It can analyse the function and depending on how complex the
function is it might be able to optimise the loop a little but in the case
of a well optimised sine function optimisation becomes very limited.

If however the compiler "knows" about the sin function (because the
compiler writer has given it special attributes that the compiler can
use) it could optimise this loop by building a lookup table at compile
time as:
static xxx
        own_sin_tbl[] = {sin(0), sin(1), ...

        for (j=0; j<10; j++)
        { arr[j] = own_sin_tbl[j];
        }

The important point here is not to focus on the sine function itself but
on the fact that a function is involved. Using functions (and this is
primarilly what libraries use) hinders the compilers ability to analyse
the intent of the programmer. Whereas having the compiler understand more
of the source allows it to better analyse the intent.

Going a bit further, if I wrote a simple search function such as

struct MY_STRUCT
        { int id;
                int mask1, mask2;
        };

int search(int x, int cnt, struct MY_STRUCT arr[])
{
        int j;

        for (j=0; j<cnt; j++)
        {
                if (x == arr[j].id)
                { return j;
                }
        }

        return -1;
}

then I could use this in C as:

static const struct MY_STRUCT predef_arr[] =
        {
                { 5, 0xfe, 0x11},
                { 7, 0xfc, 0x22},
                {11, 0xe1, 0x33},
        };

static const int predef_cnt = 3;

main()
{
...

        mask1 = 0xff;
        mask2 = 0x00;

        res = search(7, predef_cnt, predef_arr);

        if (res != -1)
        {
                mask1 = predef_arr[res].mask1;
                mask2 = predef_arr[res].mask2;
        }
...
}

now if search were actually part of the language as in:

        res = SEARCH ARRAY=predef_arr LENGTH=predef_cnt WITH KEY=id FOR 7;

then the compiler would be in the position to simply generate the
equivalent of:

main()
{
...

        mask1 = 0xfc;
        mask2 = 0x22;
...
}

Ok so from all this you might get the impression that what I'm talking
about is purely optimisation related, it's not. It's about making it
easier for the programmer to write correct code and the compiler to
understand the code and so catch mistakes at compile time - good
optimisation is actually a side effect.

In the above example LENGTH was given as predef_cnt but this could have
easily been omitted since the compiler can see the length of the array.
Thus eliminating the need for predef_cnt (and maintaining it if predef_arr
actually changes). If the array were of integers SEARCH wouldn't even have
needed a WITH KEY component :-)

Having built-in types such as LIST, STACK, STRING greatly enhance the
compilers ability to track correct usage and reduce source code size
making it easier for the programmer to see the wood for the trees.

>
> > I think if you look at a high level language like Java or even the
> > executable produced by something like a C++ compiler, you will find
> > that the native machine code being executed is not the problem - the
> > problem is all the dynamic memory management that is going on.
> > Objects being created and destroyed just so that trivial operations
> > can be performed without impacting on other objects.
>
> You're probably right. Heap management and garbage collection, pointer
> and reference mechanics, support for polymorphism and virtual functions
> -- all in microcode, directly executed, wouldn't that be nice? But by
> judging from the

???
 
>
> > Personally I think if you really want to optimise a processor to
> > execute high level code more efficiently then it needs an evaluation
> > stack (kind of like FORTH) [...]
>
> FORTH again... shouldn't it have had more success? :)

As Olin points out, large complex programs are very difficult to write and
maintain in FORTH. But I wasn't actually advocating FORTH itself just the
evaluation stack.

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 Sun, 5 Jul 2009, Olin Lathrop wrote:

> sergio masci wrote:
> >> Even if you take this as a excuse for why C was so poorly designed, it
> >> still doesn't excuse its widespread use today.  C got popular because
> >> it tagged along with Unix and for other marketing reasons like that
> >> compilers were available cheaply or freely.
> >
> > Don't be so dismissive of that tiny little word "free". It tends to be a
> > VERY powerful incentive.
>
> I wasn't being dismissive about it and completely agree.
>
> > Ok so rather than simply write another C compiler I took the plunge and
> > tried to do something better. How far did this actually get me with you
> > an affirmed C detractor. In another post (same thread) you actually
> > mention that although XCSB is purportedly not a toy and it is not C you
> > haven't tried it. I've tried on various occations to get feedback from
> > you (through this list) about what features you would like to see in a
> > language but all I've been able to glean is that you'd like very strong
> > type checking and the language should really be PASCAL.
>
> I never said the ideal language is Pascal, only that Pascal did get a lot of
> things right and I usually use it as a counter-example to C because I know
> it pretty well and I have my own version of it.
>
> There are several reasons I haven't tried XCSB.  First no customer has
> demanded it, while they have demanded HiTech C and Microchip C18
> occasionally.  As a result I have both of them.  Second, no matter how great
> a job you do, I'm nervous about anything not from Microchip.  If Microchip
> had a compiler for a decent language, I might actually try it, especially if
> it didn't do some of the brain dead things C18 does (really stupid stack and
> calling conventions).  Third, while I'm not stuck on Pascal, Basic is a real
> turn off.  Whether deserved or not, there is a certain perception about it.

I hear what you're saying.

> Even when customers don't care much what language I use, I don't want to
> have the conversation of having to defend the use of Basic.  You would have
> been better off calling it something else even if the syntax was heavily
> based on Basic.

Maybe I should just rename it to !C

>
> So where does that leave people who want to innovate and provide a better
> language?  Unfortunately in today's world of microcontrollers I think a new
> language can only come about one of two ways.  First a company like
> Microchip supports it as part of their development suite.  Second anyone
> else has to provide it for free so some people who are less in a position
> like I am can experiment with it and make it gain some ground.  If it does
> and the hardware vendor picks it up, guys like me can finally get to use it.
> For my purposes a standard is not that big of a deal since I'm not too
> concerned about porting code between PICs and other microcontrollers.
> Eventually for general purpose wide acceptance a standard is important
> though.
>
> I think if you want to see XCSB take off, you need to get Microchip
> interested and have it become theirs with you somehow getting paid off in
> the process.  Unfortunately I think that will be a hard sell because
> Microchip probably peceives little demand for something better than C.

Yeah I don't think that's going to happen.

> Hence point that started all this.  It will take a lot of users bitching and
> moaning about C before the likes of Microchip will pay any attention and try
> to provide something better.  And that can't happen until people widely
> agree that C sucks.

Yeah it really p*ss' me off that languages have stagnated so much over the
last 30 years.

>
> > Yes there are things I really hate about C but I really don't want to be
> > tied into just implementing a PASCAL compiler - I want to do better.
> >
> > I'll make you an offer, if you want to produce a free PASCAL compiler
> > for the 16 series, I'll let you use my XCASM assembler as a back end
> > free of charge provieded it is tied to the compiler so that it can't be
> > used as a standalone tool.
>
> Creating a new language for embedded programming, but also useful for
> general programming, is actually something on my list of fun things to do.
> There are lots of other things on that list (like making a flat sheet of
> foam core fly, or at least glide in a controlled way), so my bandwidth for
> that is extremely limited.  All I've done so far is jot down a few notes on
> syntax and constructs.
>
> What does the interface to the back end of your compiler look like?  What
> language is it written in?  What output files does it produce?  Does it
> create debug records compatible with MPLAB so that you can do source level
> debugging in MPLAB?

I'll try to answer these in the order I think they are most important to
you.

1... It does not generate MPLAB compatible debug info although it does
generate debug info which could be put through a translator to generate
MPLAB compatible debug info.

2... The back end of the compiler is XCASM and the XCSB compiler emits low
level XCASM assembler statements for memory / variable allocation and high
level XCASM assembler statements (e.g. .let A=B+C) to do the brunt of the
code generation. Function calls, argument passing, array indexing,
pointer dereferenceing temporary memory allocation (for expresion
evaluation) are all handled by the high level XCASM code generator
e.g. .let arr[j] = arr[j+1] + fred(A, B, C) + *(ptr + j * 4)

3... the interface language is XCASM assembler however XCASM produces an
intermediate internal code which you would not normally need to play with
which allows the compiler writer to tune the generated output to strange
architectures. NOTE XCASM is actually a meta assembler.

4... Both XCSB and XCASM are written in C++

 >

> I already have the front end of a Pascal compiler since that's how my source
> to source translator works.  The front end reads the input source and builds
> in-memory structures that define the program in a language-independent way.
> The front end then exits and the back end runs to write out the program
> definition in whatever output language that back end supports.  SST has
> multiple front and back ends, and they can be independently chosen.  In
> theory a back end could be created that drives your PIC code generator, but
> I'd need to know a lot more about it before getting any idea how much work
> that would be.  I just checked, and the C back end of SST is about 8500
> lines of code, for example.
>
> > I agree that the resulting code would not have been less efficient but I
> > disagree that "the compiler would not have been much harder to write".
> > The early C compilers didn't even deal with function prototypes. A lot
> > of time was wasted actually tracking down bugs that were the result of
> > passing the wrong type of parameter to a function.
>
> I just checked, and the Pascal front end to SST is 7500 lines of code plus
> another 750 line syntax defintion file.  Together these not only define the
> syntax, parse it, and translate the code to language-independent data
> structures, but also perform all the type checking.  For a competent
> software engineer setting out to write a whole new program on the scope of a
> compiler, I think less than 10000 lines qualifies as "not hard".

If you need to email me offlist please do not send email to my list
address but instead send it to sergio at xcprod dot com

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

[Gerhard Fiedler]

sergio masci wrote:

> 4... Both XCSB and XCASM are written in C++

I find this funny, in the context of this discussion... While many of
C's shortcomings have been addressed in C++, much of Olin's criticism of
C still applies to C++.

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

[CDB-3]

I'm surprised at how far off topic this thread has become.

My question was answered looonnng ago, I wonder if this topic tangent
which also interests me shouldn't perhaps become OT or Tech or
something?

Colin
--
cdb, colin@... on 6/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

[William "Chops" Westfield]

On Jul 5, 2009, at 1:09 PM, sergio masci wrote:

> Yes but the problem is: are you prepared to take the risk and try a  
> new programming language just to discover its strengths and  
> weaknesses, to see it really will save you a great deal of time in  
> both development and maintinance? And if you are, is your boss?

It's worse than that.  Since a big point about using C now is that it  
allows code to be (mostly) portable between different CPUs, any would-
be replacement has to appear nearly simultaneously on at least a half-
dozen platform to even begin to be taken seriously.  (This doesn't  
reflect on Olin's point that C "should have been better."  It just  
reflects the way things ARE, now.)

(Hmm.  I wonder if I can claim the reverse?  That languages that had  
ANY standardization effort AFTER "C" became known should have paid  
more attention to why C was gaining popularity?  Why didn't Pascal, AS  
A STANDARDIZED LANGUAGE, pick up features that would have made it more  
acceptable as a systems programming language?  People were still  
writing operating systems code in Assembly Language well into the  
1980s, right?  (Was it VMS that was mostly in Bliss?  (Now there was  
another language failure.))

BillW

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

[Tamas Rudnai]

Maybe it is just the time people start to realize that few operators like
++, << or += that virtually makes C as a "system programming language" is
not everything.

Tamas



On Mon, Jul 6, 2009 at 7:27 AM, William "Chops" Westfield <westfw@...>wrote:

>
> On Jul 5, 2009, at 1:09 PM, sergio masci wrote:
>
> > Yes but the problem is: are you prepared to take the risk and try a
> > new programming language just to discover its strengths and
> > weaknesses, to see it really will save you a great deal of time in
> > both development and maintinance? And if you are, is your boss?
>
> It's worse than that.  Since a big point about using C now is that it
> allows code to be (mostly) portable between different CPUs, any would-
> be replacement has to appear nearly simultaneously on at least a half-
> dozen platform to even begin to be taken seriously.  (This doesn't
> reflect on Olin's point that C "should have been better."  It just
> reflects the way things ARE, now.)
>
> (Hmm.  I wonder if I can claim the reverse?  That languages that had
> ANY standardization effort AFTER "C" became known should have paid
> more attention to why C was gaining popularity?  Why didn't Pascal, AS
> A STANDARDIZED LANGUAGE, pick up features that would have made it more
> acceptable as a systems programming language?  People were still
> writing operating systems code in Assembly Language well into the
> 1980s, right?  (Was it VMS that was mostly in Bliss?  (Now there was
> another language failure.))
>
> BillW
>
> --
> 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

[Alan B. Pearce-2]

>> 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.
>
>You forgot the "conformance" aspect. Ada is a registered trademark
>of the US DoD. To write an Ada compiler, the vendor needs (needed?)
>to jump through DoD hoops. The compiler needed to be certified and
>anyone using the compiler could not do DoD work if the certification
>had expired (they had to be recertified every year) without special DoD
> >excemption.
>
>With all this BS going on, it's no wonder Ada never really took off.

IIRC one of the things about producing an ADA compiler, was that you could
not make a compiler that dealt with only a subset of the language. That is
what really killed it for small processors - who needed all that floating
point etc functionality that would never actually be used?

>Yes but most people that like ladder logic are not expert programmers.

Doesn't this come down to a comment someone earlier made about C? The tool
for the job that does what is needed, and can deal with the problem the
programmer specifies? AIUI situations where PLCs with ladder logic are used
tend to be things where blinding speed isn't required anyway, it is
generally better to be sure this valve has closed before opening that one
type of stuff.

--
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 2:58 AM, Tamas Rudnai<tamas.rudnai@...> wrote:
> Maybe it is just the time people start to realize that few operators like
> ++, << or += that virtually makes C as a "system programming language" is
> not everything.
>
> Tamas



Can you translate this for me?

--
Martin K.
--
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:

>>> Yes I can see where you are comming from. So what would you say to a
>>> programmer who points at your generated code and laughing says "I
>>> could have done that in half the number of machine code
>>> instructions" using C. If your C "successor" is going to stand any
>>> chance of competeing with C, it's got to generate code that's at
>>> least on a par with it.
>>
>> If it's competing on its turf, then yes. If I can say "I have
>> developed the application in 10% of the time it would have taken to
>> develop it in C", then it depends. That's probably the reason why C
>> (and assembly) is not that popular with bigger systems,
>> notwithstanding its popularity with smaller systems.
>
> Yes but the problem is: are you prepared to take the risk and try a
> new programming language just to discover its strengths and
> weaknesses, to see it really will save you a great deal of time in
> both development and maintinance? And if you are, is your boss?

People (and their bosses :) do it all the time. C# came out of (almost)
nowhere a few years ago. Ruby is quite recent, too. Both are reasonably
popular now. I'm sure you can find other examples.

> It's all well and good reading about a language or paradigm that will
> save you tons of money and time but having read all these over
> enthusiastic claims in the past and found them to be false (if not
> down right lies), you tend to treat new claims (that you "hear"
> about) with a good deal of sceptisism.

Of course. This is what I've written about before: it's not so much
about the "computer science quality" of the language, but about a number
of other factors. I'm not sure what it is, but it's pretty obvious that
it's not the mere programming quality of a programming language that
makes it popular (or not).

>>>> It seems a certain part of the engineering population thinks that
>>>> ladder logic is an adequate way to describe their control
>>>> problems, yet ladder logic compilers are definitely unpopular with
>>>> the micro crowd. There seem to be groups that have different views
>>>> of what is the easiest way to describe a problem.
>>>
>>> Yes but most people that like ladder logic are not expert programmers.
>>
>> Most people, and even most programmers, are not expert programmers (by
>> definition... :)
>
> Ok, ok, back to the 99% :-)
>
> Let me change that then to: most people that make a living as a
> professional programmer.

But still... they get work done. And apparently they (and their bosses
:) don't think that learning C (or whatever other programming language)
would help them getting it done more efficiently -- or they would hire
programmers.


> BTW I guess by XSBC you actually mean XCSB :-)

Yes. You can send this to your marketing department -- I never can
remember which way it is :)

>>> But most problems can be broken down into much smaller well defined
>>> processes such as search, sort, append, remove etc. which a
>>> language should be able to apply to basic data types such as lists,
>>> sets, heaps, arrays, strings etc. For any really complex not yet
>>> thought-of domains we have libraries. I am so fed up with the
>>> notion that we need libraries for everything, that the language
>>> needs to be so rediculasly simply as to not be able to understand
>>> types such as lists, strings, dynamic array etc. when these types
>>> are so common and well understood.
>>
>> I for one never understood this "war" between language and libraries. I
>> don't really care that much whether C++ has a decent array type built
>> into the language or whether there are the C-style arrays for backwards
>> compatibility and as a decent solution there is std::vector from the
>> standard library. The standard libraries are, at least with C and C++,
>> part of the language specification.
>>
>> Then there are those cases where I still code my own containers, because
>> for the one or other requirement, the standard containers don't fit my
>> bill. Probably no language built-in container can do it all; there too
>> many different sets of requirements with different solutions.
>>
>> You probably have a point with strings (in C and C++), but there is the
>> dreaded backwards compatibility that sooner or later hits everything
>> that is used for long enough, and so C is pretty much stuck with the
>> half-assed string implementation it has. In C++ there is std::string,
>> which works for many cases well enough (and again I don't really care
>> that much that this is from a library).
>
> Yes this point seems to elude most programmers.
>
> [loop optimization ...]
>
> Now if we introduce a function the above optimisations break
> e.g.
> for (j=0; j<10; j++)
> { arr[j] = sin(j);
> }
>
> This is because the compiler doesn't really know anything about the
> function. It can analyse the function and depending on how complex
> the function is it might be able to optimise the loop a little but in
> the case of a well optimised sine function optimisation becomes very
> limited.
>
> If however the compiler "knows" about the sin function (because the
> compiler writer has given it special attributes that the compiler can
> use) it could optimise this loop by building a lookup table at compile
> time as:
> static xxx
> own_sin_tbl[] = {sin(0), sin(1), ...
>
> for (j=0; j<10; j++)
> { arr[j] = own_sin_tbl[j];
> }

Here you have a point, but I'd say that this code (as C code for a small
micro) is badly written. Really badly. arr[j] should be initialized with
compile-time constants, not at run-time. You can say that this is the
compiler's job, but the problem is, again, that there are so many
different ways to calculate sin(). The compiler doesn't know which one I
think is adequate for my purposes; do I need 2 digits precision, or 6,
or 12? The code size and/or execution time of the function varies
substantially with the required precision.


> The important point here is not to focus on the sine function itself
> but on the fact that a function is involved. Using functions (and
> this is primarilly what libraries use) hinders the compilers ability
> to analyse the intent of the programmer. Whereas having the compiler
> understand more of the source allows it to better analyse the intent.

Yes, I get that. But the compiler can't know a few things around my
requirements, and I may be better able to choose which function
implementation is more adequate.

Regarding the intent, a good definition of a library function (think the
C++ standard library) explains quite clearly the intent. It doesn't nail
down the implementation details of the functions, though. C doesn't do
it, but there's nothing in the above that would prevent a compiler to
actually call at compile time the library function to calculate that
array. It doesn't have to be built in for that; it just has to know
which library to use (at compile time).

> Going a bit further, if I wrote a simple search function such as
>
> struct MY_STRUCT
> { int id;
> int mask1, mask2;
> };
>
> int search(int x, int cnt, struct MY_STRUCT arr[])
> {
> int j;
>
> for (j=0; j<cnt; j++)
> {
> if (x == arr[j].id)
> { return j;
> }
> }
>
> return -1;
> }
>
> then I could use this in C as:
>
> static const struct MY_STRUCT predef_arr[] =
> {
> { 5, 0xfe, 0x11},
> { 7, 0xfc, 0x22},
> {11, 0xe1, 0x33},
> };
>
> static const int predef_cnt = 3;
>
> main()
> {
> ...
>
> mask1 = 0xff;
> mask2 = 0x00;
>
> res = search(7, predef_cnt, predef_arr);
>
> if (res != -1)
> {
> mask1 = predef_arr[res].mask1;
> mask2 = predef_arr[res].mask2;
> }
> ...
> }
>
> now if search were actually part of the language as in:
>
> res = SEARCH ARRAY=predef_arr LENGTH=predef_cnt WITH KEY=id FOR 7;
>
> then the compiler would be in the position to simply generate the
> equivalent of:
>
> main()
> {
> ...
>
> mask1 = 0xfc;
> mask2 = 0x22;
> ...
> }

This doesn't require that SEARCH is part of the compiler; it merely
requires that the semantics of SEARCH are well-defined. It could just as
well be a library function with semantics that are specified so that the
compiler can know what to do.

But again, like above with the sin() example, code like this should
actually be compile-time constants, not run-time calculations. The
program writer should clearly distinguish between values that are known
before the program runs and values that are dependent on run-time
events. The examples you showed are only relevant if the programmer
doesn't do this.


> Ok so from all this you might get the impression that what I'm talking
> about is purely optimisation related, it's not. It's about making it
> easier for the programmer to write correct code and the compiler to
> understand the code and so catch mistakes at compile time - good
> optimisation is actually a side effect.

I get this, but I think a library with clearly defined semantics goes a
long ways towards that. And a programmer who clearly distinguishes
between stuff that's known at compile time and stuff that can only be
known when the program runs also helps.


> Having built-in types such as LIST, STACK, STRING greatly enhance the
> compilers ability to track correct usage and reduce source code size
> making it easier for the programmer to see the wood for the trees.

Right, but again... The C++ standard library, for example, has quite
good implementations of standard containers, yet I find myself creating
my own containers or using different containers from other libraries,
for specific requirements that the standard containers don't satisfy. A
list or stack is a concept, with many different possible implementations
that satisfy different requirements. And I suspect that the smaller the
micro it runs on, the more limited the resources are, the more important
are the differences between different implementations.

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]

William Chops" Westfield" wrote:
> (Hmm.  I wonder if I can claim the reverse?  That languages that had
> ANY standardization effort AFTER "C" became known should have paid
> more attention to why C was gaining popularity?  Why didn't Pascal, AS
> A STANDARDIZED LANGUAGE, pick up features that would have made it more
> acceptable as a systems programming language?

First, Pascal didn't come after C, it preceeded it.  However, that wouldn't
have prevented others from trying to standardize their variant later.  I
think the reason is that this wasn't how things were done and how people
were thinking back then.  Remember, this was back when every computer
manufacturer had their own operating system and unique CPU.  About all you
could count on was that a Fortran compiler was available with everything
else pretty much proprietary.  And even then, every vendor had their
proprietary extensions to Fortran to give themselves a competitive
advantange and hopefully lock in their customers a bit.  Those that
developed their own useful Pascal variants saw them like intellectual
property that gave their platform a competitive advantage.  This was the
prevailing mindset until the late 1980s when Sun overtook the workstation
market on the strength of openess.


********************************************************************
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]

Tamas Rudnai wrote:

> Maybe it is just the time people start to realize that few operators like
> ++, << or += that virtually makes C as a "system programming language" is
> not everything.

Or maybe it's time for some people to start realizing that the success
of C is based on a bit more than operators like ++ or << :)

I really don't think the language features (as in "computer science")
have much to do with its success. As long as people only look at the
language (programmer's view), they're missing the bigger picture -- the
part of it that makes or doesn't make a language successful.

C isn't successful in all areas. It probably was the first language for
server-side creation of dynamic content for web sites, but it has been
replaced by PHP, Perl, Java, Ruby, ASP.

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:20 AM, Gerhard
Fiedler<lists@...> wrote:
> People (and their bosses :) do it all the time. C# came out of (almost)
> nowhere a few years ago. Ruby is quite recent, too. Both are reasonably
> popular now. I'm sure you can find other examples.


Perl, Python, Haskell, ...
Any of which can be compiled so should not be limited by being called
"scripting" languages.
--
Martin K.
--
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 Mon, 6 Jul 2009, Gerhard Fiedler wrote:

> sergio masci wrote:
> >

> Yes. You can send this to your marketing department -- I never can
> remember which way it is :)

Ok I'll be sure to pass this on to the left side of my desk :-)

> >
> > Yes this point seems to elude most programmers.
> >
> > [loop optimization ...]
> >
> > Now if we introduce a function the above optimisations break
> > e.g.
> > for (j=0; j<10; j++)
> > { arr[j] = sin(j);
> > }
> >
> > This is because the compiler doesn't really know anything about the
> > function. It can analyse the function and depending on how complex
> > the function is it might be able to optimise the loop a little but in
> > the case of a well optimised sine function optimisation becomes very
> > limited.
> >
> > If however the compiler "knows" about the sin function (because the
> > compiler writer has given it special attributes that the compiler can
> > use) it could optimise this loop by building a lookup table at compile
> > time as:
> > static xxx
> > own_sin_tbl[] = {sin(0), sin(1), ...
> >
> > for (j=0; j<10; j++)
> > { arr[j] = own_sin_tbl[j];
> > }
>
> Here you have a point, but I'd say that this code (as C code for a small
> micro) is badly written. Really badly. arr[j] should be initialized with
> compile-time constants, not at run-time. You can say that this is the
> compiler's job, but the problem is, again, that there are so many
> different ways to calculate sin(). The compiler doesn't know which one I
> think is adequate for my purposes; do I need 2 digits precision, or 6,
> or 12? The code size and/or execution time of the function varies
> substantially with the required precision.

You are explicitly seeing sin() where I have tried highlighting the brick
wall between the compiler and the knowledge excapsulated in a library
function.

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).

Yes the compiler could try to evaluate the 'blackbox' function at compile
time in order to generate a compile time constant but this is not the
point. It is a way of getting the same result as would be obtained as a
side effect "of the point".

Let's try something a little bit more interesting:

void delete_item(int pos, int *len, int arr[])
{
        int j;

        for (j=pos; j<*len; j++)
        {
                arr[j] = arr[j+1];
        }

        *len--;
}

void insert_item(int pos, int val, int *len, int arr[])
{
        int j;

        for (j=*len-1; j>pos; j--)
        {
                arr[j] = arr[j-1];
        }

        *len++;

        arr[pos] = val;
}

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);

I can see how you would do this easily if the compiler actually new the
intent of delete_item and insert_item.

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? 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?

>
>
> > The important point here is not to focus on the sine function itself
> > but on the fact that a function is involved. Using functions (and
> > this is primarilly what libraries use) hinders the compilers ability
> > to analyse the intent of the programmer. Whereas having the compiler
> > understand more of the source allows it to better analyse the intent.
>
> Yes, I get that. But the compiler can't know a few things around my
> requirements, and I may be better able to choose which function
> implementation is more adequate.
>
> Regarding the intent, a good definition of a library function (think the
> C++ standard library) explains quite clearly the intent. It doesn't nail
> down the implementation details of the functions, though. C doesn't do
> it, but there's nothing in the above that would prevent a compiler to
> actually call at compile time the library function to calculate that
> array. It doesn't have to be built in for that; it just has to know
> which library to use (at compile time).
>
>
> > Going a bit further, if I wrote a simple search function such as
> >
> > struct MY_STRUCT
> > { int id;
> > int mask1, mask2;
> > };
> >
> > int search(int x, int cnt, struct MY_STRUCT arr[])
> > {
> > int j;
> >
> > for (j=0; j<cnt; j++)
> > {
> > if (x == arr[j].id)
> > { return j;
> > }
> > }
> >
> > return -1;
> > }
> >
> > then I could use this in C as:
> >
> > static const struct MY_STRUCT predef_arr[] =
> > {
> > { 5, 0xfe, 0x11},
> > { 7, 0xfc, 0x22},
> > {11, 0xe1, 0x33},
> > };
> >
> > static const int predef_cnt = 3;
> >
> > main()
> > {
> > ...
> >
> > mask1 = 0xff;
> > mask2 = 0x00;
> >
> > res = search(7, predef_cnt, predef_arr);
> >
> > if (res != -1)
> > {
> > mask1 = predef_arr[res].mask1;
> > mask2 = predef_arr[res].mask2;
> > }
> > ...
> > }
> >
> > now if search were actually part of the language as in:
> >
> > res = SEARCH ARRAY=predef_arr LENGTH=predef_cnt WITH KEY=id FOR 7;
> >
> > then the compiler would be in the position to simply generate the
> > equivalent of:
> >
> > main()
> > {
> > ...
> >
> > mask1 = 0xfc;
> > mask2 = 0x22;
> > ...
> > }
>
> This doesn't require that SEARCH is part of the compiler; it merely
> requires that the semantics of SEARCH are well-defined. It could just as
> well be a library function with semantics that are specified so that the
> compiler can know what to do.
>
> But again, like above with the sin() example, code like this should
> actually be compile-time constants, not run-time calculations. The
> program writer should clearly distinguish between values that are known
> before the program runs and values that are dependent on run-time
> events. The examples you showed are only relevant if the programmer
> doesn't do this.

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.

>
>
> > Ok so from all this you might get the impression that what I'm talking
> > about is purely optimisation related, it's not. It's about making it
> > easier for the programmer to write correct code and the compiler to
> > understand the code and so catch mistakes at compile time - good
> > optimisation is actually a side effect.
>
> I get this, but I think a library with clearly defined semantics goes a
> long ways towards that. And a programmer who clearly distinguishes
> between stuff that's known at compile time and stuff that can only be
> known when the program runs also helps.
>
>
> > Having built-in types such as LIST, STACK, STRING greatly enhance the
> > compilers ability to track correct usage and reduce source code size
> > making it easier for the programmer to see the wood for the trees.
>
> Right, but again... The C++ standard library, for example, has quite
> good implementations of standard containers, yet I find myself creating
> my own containers or using different containers from other libraries,
> for specific requirements that the standard containers don't satisfy. A
> list or stack is a concept, with many different possible implementations
> that satisfy different requirements. And I suspect that the smaller the
> micro it runs on, the more limited the resources are, the more important
> are the differences between different implementations.
>

The standard template library is still a brick wall to the compiler. It
can do a lot of optimisations in situ which give the illusion that the
compiler understands what the intent is but the reallity is that the
compiler is just blindly reducing intermediate code as much as it can
(kind of like macros on steroids) and then using what's left to generate
the executable. It's not looking for special patterns of use and
optimising at a high level which is what YOU are doing when you create
your special optimised containers.

Another way to look at this, say you write:

        unsigned char x, j;

        x = j * 2;

The compiler can actually replace "* 2" by "<< 1" because it looks for the
special combination "* 2" operating on an integer. Also the compiler could
optimise "x = j << 1" for the PIC into

        rlf j,w
        movwf x

because it sees the combination of '=' and '<< 1'

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?

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. How would you do that with library functions (even allowing for
overloading)?

How would the compiler do the promotion here?

        assign(&x, div(y, z));


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

[M.L.-2]

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 - in any case and you should typecast it to float.
x = (float)(y/z);

I realize this wasn't your point, but it's worth mentioning.
--
Martin K.

--
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:

> William Chops" Westfield" wrote:
>> (Hmm.  I wonder if I can claim the reverse?  That languages that had
>> ANY standardization effort AFTER "C" became known should have paid
>> more attention to why C was gaining popularity?  Why didn't Pascal,
>> AS A STANDARDIZED LANGUAGE, pick up features that would have made it
>> more acceptable as a systems programming language?
>
> First, Pascal didn't come after C, it preceeded it.  However, that
> wouldn't have prevented others from trying to standardize their
> variant later.  I think the reason is that this wasn't how things
> were done and how people were thinking back then.  Remember, this was
> back when every computer manufacturer had their own operating system
> and unique CPU.  

The ANSI started with standardization of C in 1983. It became an ISO
standard in 1990.

> 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...

> 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.

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. Which again is the
likely cause for the lack of popularity of each of them. For what it
seems, these Pascal dialects didn't only add features to the original
language, they also changed features and omitted others. This of course
doesn't help.

(BTW, you sound almost like the ones that are trying to defend the C
shortcomings as features in the language wars :)

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