Re using BREAK in 'C'

[Gerhard Fiedler]

Olin Lathrop wrote:

>> But you're talking about popularity, availability.
>
> No, I'm specifically not.  I understand how C got where it is and
> that today you have to use it regardless of technical merits.  

Didn't you write earlier in this thread:

:: All I'm looking for is some outcry from the minority rest of us to
:: keep pointing out the faults in C and complain about wanting
:: something better. It's not easy to change such intrenched thinking,
:: but if we keep beating on it more and more people may slowly realize
:: that C is a really bad idea.


> The part I'm trying to point out is that C sucks technically, because
> too many sheeple use C and don't see a problem with that.  I'm not
> saying there is a handy solution because I don't see one either.

Well, in the absence of a better solution, it seems that C is the best
solution -- now, in some (many) settings. This is probably the reason
why most people use it, and it has nothing to do with them being
sheeple. (Well, I'm one of them, so it's kind of obvious that I would
think so :)


> But the realization that it would be nice if there was one is
> something too many people haven't made yet, and that's what I'm
> trying to get them to see.  There are still people in this world that
> actually *like* C (and I don't mean in the business sense), as
> evidenced by several of the responses here.

You may not believe it, but there are people who actually *like*
assembly :)  Not that different from liking C, IMO.


>> This is the thing you seem to get confused. The reason why C is more
>> popular has nothing to do with computer science concepts,
>
> No, in fact I've been trying to point that out.

Then we agree on that. IMO it's usually a mixture of long-term
availability, support for many targets, well specified (and a single
spec), popularity, and other such criteria -- but not on its merits as
well-designed programming language, in the academic sense of it.

But in a business setting, the latter has some impact, but other
criteria have much more impact. And those other criteria may make it a
sound decision to use C -- despite its shortcomings. The shortcomings of
the alternatives are even worse. And that's why C is not, all in all,
"bad".

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

[Tamas Rudnai]

Just installed FreePascal in my linux box and it's great :-) It even has the
old Borland Pascal style IDE in text user interface with the very same menu
alignments and keyboard mappings. I had some fun time to remembering the old
WordStar hotkeys but it seems after 10 years or even more can still remember
^KB & ^KK :-)

Anyway, my Pascal knowledge fade a bit away so have to refresh it and made
some tests for auto and static procedure/function variables just for fun.
Basically 'test' is a recursive procedure so that the staticness of
variables can be tracked down easily. The idea is that an auto variable
keeps it's value on the same recursion level so when returning from the
higher level we can see if the variable changed or not.

As you can see the variables declared with 'const' are really static (like
the 'static' directive in C) while the ones with the 'var' are 'auto'
variables (aka sits on the stack). The interesting part is that if you
specify a 'var' to located on top of a 'const' then it becomes static as you
just have told the compiler to place the variable on the static data memory
area instead of the stack.

Here is the source of this test:

program test;
uses crt;

const
  globConst: Integer = 999;


procedure test ( par: Integer );
const
  v1: Integer = 0;  { it's a static variable }
var
  v2: Integer;      { it's an auto variable }
  v3: Integer absolute globConst;   { this is supposed to be an auto but it
binds to a global static instead }
begin
  v1 := par;
  v2 := par;
  v3 := par;

  write('  test1 = ', v1);
  write('  test2 = ', v2);
  writeln('  test3 = ', v3);
  writeln('--------------');

  if par < 5 then test( par + 1 );

  write('  test1_exit = ', v1);
  write('  test2_exit = ', v2);
  writeln('  test3_exit = ', v3);
  writeln('--------------');
end;


begin
  writeln('variable test');
  test(1);
end.

---RESULTS---

variable test
  test1 = 1  test2 = 1  test3 = 1
--------------
  test1 = 2  test2 = 2  test3 = 2
--------------
  test1 = 3  test2 = 3  test3 = 3
--------------
  test1 = 4  test2 = 4  test3 = 4
--------------
  test1 = 5  test2 = 5  test3 = 5
--------------
  test1_exit = 5  test2_exit = 5  test3_exit = 5
--------------
  test1_exit = 5  test2_exit = 4  test3_exit = 5
--------------
  test1_exit = 5  test2_exit = 3  test3_exit = 5
--------------
  test1_exit = 5  test2_exit = 2  test3_exit = 5
--------------
  test1_exit = 5  test2_exit = 1  test3_exit = 5
--------------

Tamas

>
>
> Of course the choice of section name may be dependent on linker conventions
> and definitions in other non-code files, such as the MPLINK control file on
> PIC targets.
>
>
> ********************************************************************
> 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
>

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

[Harold Hallikainen-2]

MANY years ago, I worked on a product designed with Turbo Pascal under
CP/M. The final hardware had the code running out of EPROM, variables in
RAM, and no OS. We made no OS calls and did system initialization (setting
up the stack pointer, etc.) before starting to execute our code (I think
it was at 0x100). This was all with a Z80. Worked pretty well. This
must've been 25 to 30 years ago...

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
--
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 made this OT as it isn't reaaly Pic'ish anymore.

:: As you can see the variables declared with 'const' are really
:: static (like
:: the 'static' directive in C)

:: const
::  globConst: Integer = 999;
::
::
:: procedure test ( par: Integer );
:: const
::  v1: Integer = 0;  { it's a static variable }

Surely that goes against what a const is, in that a constant is a
contract between the coder and the compiler that that value will NEVER
alter?

I'm off to rediscover my Pascal tutorial books, see what they say.

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

[Tamas Rudnai]

Yes I remember even in DOS they have been compiled to the COM file format --
which is not even a format just a 64k-0x100  memory space in disk. Before
that there was the PSP with FCB and some other CP/M heritage -- eh, good old
times :-)

Tamas


On Fri, Jul 3, 2009 at 12:44 AM, Harold Hallikainen
<harold@...>wrote:

> MANY years ago, I worked on a product designed with Turbo Pascal under
> CP/M. The final hardware had the code running out of EPROM, variables in
> RAM, and no OS. We made no OS calls and did system initialization (setting
> up the stack pointer, etc.) before starting to execute our code (I think
> it was at 0x100). This was all with a Z80. Worked pretty well. This
> must've been 25 to 30 years ago...
>
> Harold
>
> --
> FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
> opportunities available!
> --
> 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

[Tamas Rudnai]

On Fri, Jul 3, 2009 at 12:48 AM, cdb <colin@...> wrote:

> I made this OT as it isn't reaaly Pic'ish anymore.
>
> :: As you can see the variables declared with 'const' are really
> :: static (like
> :: the 'static' directive in C)
>
> :: const
> ::  globConst: Integer = 999;
> ::
> ::
> :: procedure test ( par: Integer );
> :: const
> ::  v1: Integer = 0;  { it's a static variable }
>
> Surely that goes against what a const is, in that a constant is a
> contract between the coder and the compiler that that value will NEVER
> alter?

As far as I know the original meaning of 'const' in Pascal was more like a
#define in C or even more like an EQU in asm. so

const v1 = 5345;

still works, and compiler would give you a big error if you try to assign a
value to it later on. Also if you try to bind a variable on top of it (like
in test3) then you will get a funny runtime error when you try access to it
either read or write -- no compile time error though on FreePascal at least.


However, if you give a type to that then the whole lot becomes a variable
with the difference that you have to initialize it and that the variable
becomes static (in case it was declared in your procedure). This is same
ugly as the 'static' directive in C when used it for either declaring static
variables or module scope global functions/variables -- depending on where
you use that.

Tamas

>
>
> I'm off to rediscover my Pascal tutorial books, see what they say.
>
> Colin
> --
> cdb, colin@... on 3/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
>

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

[John Ferrell-5]

I did not realize that. Thanks, I have learned an important point.

John Ferrell  W8CCW

"Extremism in defense of liberty is no vice, and moderation in pursuit of
justice is no virtue."
-Barry Goldwater
"You don't get harmony when everybody sings the same note."
-Doug Floyd

----- Original Message -----
From: "Gerhard Fiedler" <lists@...>
To: "Microcontroller discussion list - Public." <piclist@...>
Sent: Thursday, July 02, 2009 5:14 PM
Subject: Re: Re [PIC]using BREAK in 'C'

> FWIW, the C #define is /not/ a compiler directive, it is a preprocessor
> directive. If Mikroelectronica's IDE allows you to configure a command
> to be run on the file before compiling, then you can bind in a 3rd party
> preprocessor to give you this. If it doesn't but has a command line for
> the compiler, you can use a 3rd party editor or IDE and do it there.
>
> 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.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:

> As you can see the variables declared with 'const' are really static
> (like the 'static' directive in C) while the ones with the 'var' are
> 'auto' variables (aka sits on the stack).

I find this at least not intuitive. I'd expect a const to be constant.

This thing with v3 is akin (in C) to use a pointer to non-const to point
to a const. Looks like a nice hole in the typing :)

Is this really the only way to create a static variable? Can't you have
a global (that is, outside of a procedure) var section?

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

[Isaac Marino Bavaresco]

liGerhard Fiedler escreveu:
> You may not believe it, but there are people who actually *like*
> assembly :)  Not that different from liking C, IMO.

I like assembly. I like also C and Pascal, but I'm way more productive
with C.

The main reason C is more productive than assembly is because with it
one needs to write *much* less code and worry about *much* less details
than with assembly. It leaves much more time to think about the real
problem. It is also easier to to reuse code and port to different
architectures.

Pascal can generate code as efficient as C and the source is much
"prettier", but the number of architectures the code can run is much
restricted.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/ 

--
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:
>> As you can see the variables declared with 'const' are really static
>> (like the 'static' directive in C) while the ones with the 'var' are
>> 'auto' variables (aka sits on the stack).
>
> I find this at least not intuitive. I'd expect a const to be constant.

In the Pascals I am familiar with CONST defines compile time symbolic
constants only.  Certainly my version works this way, although it often
realizes these constants as static read-only variables.

Note that Tamas' code doesn't prove how exactly the compiler interpreted the
CONST symbols.  Either interpretation would have resulted in the same
output.  For that matter his code doesn't even prove the constants are
static if they are implemented as values in memory locations.  Since you can
only read them and then you always read the same value, you can't tell
whether you are reading a different memory location each time or whether the
compiler is substituting the symbol's value on the fly.

The only way to tell would be to take the address of a symbolic constant.
If you get a compile error, then its just a symbolic constant.  If it works,
then you still don't know whether the compiler created a literal only
because you asked for the address.  You can pass a symbolic constant to a
subroutine pass by reference parameter and see if the the address changes
with nesting level.  If so, then these things aren't variables at all since
the compiler is creating the argument anew each call.

It's very tricky to tell the difference, which also makes it so you don't
need to care in most cases.


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

[Bob Ammerman]

 ::
> :: procedure test ( par: Integer );
> :: const
> ::  v1: Integer = 0;  { it's a static variable }
>
> Surely that goes against what a const is, in that a constant is a
> contract between the coder and the compiler that that value will NEVER
> alter?
>
> I'm off to rediscover my Pascal tutorial books, see what they say.

I don't know about 'standard' pascal (if there is such a thing), but in
Turbo Pascal (and apparently Free Pascal)  there are two types of 'const':


const a = 10;                    { a real constant }
const a : Integer = 10;       { really an initialized static variable }

-- Bob Ammerman
RAm Systems

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

[plpeter]

C constants trace their ancestry back to when C had no types. Normally the const
is a kludge that is not enforced, iow it is a normal memory storage location in
which data is stored that has the 'const' attribute only in the compiler.
Writing code that tries to write to a const variable (!) causes a compiler
warning at most, and that can be overriden. This is sometimes used to create
code that ensures that any writes occur only at controlled locations (generating
specified tolerated warnings on compile), and nowhere else.

(aside: this is an easy way to find out whether something is changing a variable
that should not do so, while debugging code - obviously it will not catch a
recast referenced access i.e. ptr=(int *)(const int *), but the cast itself
should be caught by the compiler /aside).

The other implication is that the compiler 'knows' that a const will not change
and may use this to generate optimized or reordered code (even optimizing the
variable away entirely into a compile-time only constant symbol - I believe that
gcc -O3 does that). That can be prevented by using certain compiler flags around
the section where the const variable is declared. On embedded systems some types
of const (the ones located at a certain address with @ or linked into a segment
mapped to eeprom etc) can be desirable, to use read-only values or non-volatile
memory that gets updated by external factors. Here is an interesting discussion
about const use with volatile (!):

http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html

C is fun ! <G>

Peter


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

[Gerhard Fiedler]

Isaac Marino Bavaresco wrote:

> Gerhard Fiedler escreveu:
>> You may not believe it, but there are people who actually *like*
>> assembly :)  Not that different from liking C, IMO.
>
> I like assembly.

This wasn't meant as offensive to any assembly programmer :)

I know it can be fun -- it's just that I personally don't like it very
much... and there's this history of conversations between Olin and me.

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:

>>> As you can see the variables declared with 'const' are really static
>>> (like the 'static' directive in C) while the ones with the 'var'
>>> are 'auto' variables (aka sits on the stack).
>>
>> I find this at least not intuitive. I'd expect a const to be constant.
>
> In the Pascals I am familiar with CONST defines compile time symbolic
> constants only.  Certainly my version works this way, although it
> often realizes these constants as static read-only variables.
>
> Note that Tamas' code doesn't prove how exactly the compiler
> interpreted the CONST symbols.  Either interpretation would have
> resulted in the same output.  For that matter his code doesn't even
> prove the constants are static if they are implemented as values in
> memory locations.  Since you can only read them and then you always
> read the same value, you can't tell whether you are reading a
> different memory location each time or whether the compiler is
> substituting the symbol's value on the fly.

:: const
::   globConst: Integer = 999; {<<<}
::
:: procedure test ( par: Integer );
:: const
::   v1: Integer = 0;
:: var
::   v2: Integer;
::   v3: Integer absolute globConst; {<<<}
:: begin
::   v1 := par;
::   v2 := par;
::   v3 := par; {<<<}

It seem the compiler assigned a memory location to the constant
globConst, because v3 is pointed to that memory location. It also seems
that in the line where v3 is pointed at that memory location, the
compiler didn't really care that it was defined as a constant; it
allowed pointing a variable to it, which later was written to.

> The only way to tell would be to take the address of a symbolic
> constant. If you get a compile error, then its just a symbolic
> constant.  If it works, then you still don't know whether the
> compiler created a literal only because you asked for the address.
> You can pass a symbolic constant to a subroutine pass by reference
> parameter and see if the the address changes with nesting level.  If
> so, then these things aren't variables at all since the compiler is
> creating the argument anew each call.
>
> It's very tricky to tell the difference, which also makes it so you
> don't need to care in most cases.

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.

As he later explains, constants defined like that aren't constants, more
like static variables in C. Bad naming; nothing constant to a static
variable. 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
:)

Gerhard
--
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 Thu, 2 Jul 2009, Tamas Rudnai wrote:

> On Thu, Jul 2, 2009 at 12:12 AM, Benjamin Grant <benjamin.grant@...>wrote:
>
> > can everyone seriously stop indulging Olin in his unpopular views of C? If
> > he doesn't see the purpose of using it let him be. Who cares, you're never
> > going to win against him and he loves having this conversation so just stop
> > responding to it.
> >

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

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. It is not to micro manage the generation of an
executable such that the compiler becomes nothing more than a glorified
assembler.

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

> Michael Rigby-Jones wrote:
> > And why do you think that is?
>
> Because most of them are either the type 1 (too dumb to know the difference)
> or type 2 (irresponsible) programmers I described.  Just like 99% of
> software out there is crap, so are 90% of the programmers.

Man you are so out of touch - its much more like 99% of the programmers
out there are crap :-)

>
> > Thousands (probably millions) of people
> > successfully use C everyday without feeling the need to condemn it;
>
> That doesn't mean anything, see above.  It's been shown many times that
> popularity is no indicator of quality or technical superiority.  How many
> pet rocks were sold back in the 1970s?  Need I say more?

You leave my pet rock out of this!

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 Tue, 30 Jun 2009, Olin Lathrop wrote:

> Gerhard Fiedler wrote:
> > K+R didn't set out to create a new language. They wanted to port an
> > OS, needed something better than assembly for that ("better" in this
> > context means mostly "more portable"), and had already B available.
> > So they developed B into C, apparently making it more suitable for
> > their task at hand -- not for you or me or anybody else. I don't
> > think it became widely used outside the small scope of Unix until the
> > 80ies, by which time the major features were already mostly settled
> > -- not exactly as design from scratch, but as result of an ongoing
> > development where the language was not a goal in itself, and the
> > development of the language had to fit into all the normal resource
> > constraints.
>
> 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.

> Today we have a very different world.  Even if we accept all the above and
> understand C is required for some new projects only because it is already
> popular, what is missing is the outcry of users demanding something better.

I've seem users "demanding" something better. I've even seen users
demanding to use better C compilers than the one currently being used.
My experience: it's like farting in a hurricane!

>
> C is a horrible development language that encourages bad programming and
> bugs.

I agree completely.

>  I suspect even you largely agree with that.  I think the real problem
> is that too many software developers fall into one of two catagories:
>
>   1 - I know C, like it well enough because I don't know anything
>       better, don't want to learn something new, so I view a new
>       language as a threat because I'd have to take time out to
>       learn it.  It took me weeks to understand those pointer thingies
>       in C, and I don't want to go thru that again.
>
>   2 - I like C because I can do whatever I want without the compiler
>       whining about it.  Type checking is for sissies.  Look at this
>       really cool code I wrote that is a whole ray tracer on the back
>       of a business card.  Betcha you can't figure out how it works!
>
> Unfortunately there are sufficient numbers of type 1 (the dumb) and type 2
> (the immature) programmers out there that bosses have to cater to them and
> development software suppliers have to cater to the bosses.

My experience is slightly different. I've seen many bosses decide on using
C because they want to use a particular dev tool, library or system that
relies on C. Then these bosses go out and buy the relevent C expertise at
the lowest price they can get. The bosses are often technical idiots who
don't understand the realities of the dev tool, library or system they are
tying themselves to, they just get swept up in the marketing hype, simple
demos and promises made by the salesman.

I remember when programmers were desperatly trying to add C to their CVs
to make themselves more employable.

I've also seen many programmers reach a certain proficency in C and then
stop because they've had their hands tied with in-house coding standards.

>
> All I'm looking for is some outcry from the minority rest of us to keep
> pointing out the faults in C and complain about wanting something better.
> It's not easy to change such intrenched thinking, but if we keep beating on
> it more and more people may slowly realize that C is a really bad idea.
>

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.

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.

> > You could just as well bitch at the Pascal developers for not making
> > it a generally usable language in the first place (that is,
> > incorporating the features that later, proprietary versions added to
> > make it useable) and standardizing it. If they had done this, maybe
> > K+R would have felt it was easier to adopt the new language rather
> > than building on their code for B. But there was no new language
> > suitable for their task.
>
> Perhaps, but they still could have taken some of the concepts.  Most of
> these things don't make the compiler much harder to write or the resulting
> code any less efficient.  It's a mindset thing, and I think that's what K+R
> lacked.

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 think I have to repeat it: If someone wants to understand why C is
> > how it is, IMO it's tremendously helpful to think of it more as a
> > "portable assembly" than a "high-level language". That's how it set
> > out, that's the mind frame that determined most of its basic
> > structure. And IMO it's perfectly compatible with what it is.
>
> Right, but that mindset was itself irresponsible.  At the least then
> promoting this hack (which is after all what you describe) was then
> irresponsible.
>

Maybe it was but everyone's moral compass seems to be afected to some
degree by money and fame.

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:

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

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

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.

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.


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

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]

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.

Besides, there usually is a reason why something is free. As there is no
such thing as a free lunch, /somebody/ paid for it -- and had a reason
to pay for it. And if something similar isn't free, it's usually because
of the lack of such "somebodies" that pay for something to be free.
Again, there is usually a reason.

Also, when I started programming, neither the C compilers nor the Pascal
compilers I used were free. IIRC, Turbo Pascal was among the least
expensive ones, and that's what most people I knew used. They stopped
using it, mainly because it was a one-vendor thing which didn't give it
much of a future.


>> Even if we accept all the above and understand C is required for some
>> new projects only because it is already popular, what is missing is
>> the outcry of users demanding something better.
>
> I've seem users "demanding" something better. I've even seen users
> demanding to use better C compilers than the one currently being
> used. My experience: it's like farting in a hurricane!

I agree :)  Especially if there isn't a common idea of something better.
Demanding may be efficient for kings; "normal" people need really to do
something else to get somewhere.


>> All I'm looking for is some outcry from the minority rest of us to
>> keep pointing out the faults in C and complain about wanting
>> something better. It's not easy to change such intrenched thinking,
>> but if we keep beating on it more and more people may slowly realize
>> that C is a really bad idea.
>
> 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.

Not very far, unluckily. Your XCSB seems to be something like another
Turbo Pascal.


>> Perhaps, but they still could have taken some of the concepts.  Most
>> of these things don't make the compiler much harder to write or the
>> resulting code any less efficient.  It's a mindset thing, and I
>> think that's what K+R lacked.
>
> 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.

As Bill wrote, these early C compiler ran in 8k of memory of an early
PDP (while Pascal was developed on the most powerful mainframe of the
time). I think one really needs to consider the whole context when
talking about the decisions made during development. (Asking the authors
would probably also help.)


>>> I think I have to repeat it: If someone wants to understand why C is
>>> how it is, IMO it's tremendously helpful to think of it more as a
>>> "portable assembly" than a "high-level language". That's how it set
>>> out, that's the mind frame that determined most of its basic
>>> structure. And IMO it's perfectly compatible with what it is.
>>
>> Right, but that mindset was itself irresponsible.  

Not anymore than people programming in assembly. Where it's adequate,
it's adequate. Responsibly used it's not irresponsible.

>> At the least then promoting this hack (which is after all what you
>> describe) was then irresponsible.

It wasn't "promoted". There is no "C conspiracy". C became popular
because of certain characteristics that somehow matched certain needs,
better than alternatives available at the time the needs arose. If you
could let go of the "C irresponsible programmers conspiracy" theory and
actually look at the history, I'm sure you'd be able to identify a few
things that make sense (or made sense at the time they happened).

Later on, it's not much different than people having huge assembly
libraries and having a hard time switching to anything else because
everything else in the beginning is a hurdle and a (even if temporary)
loss of productivity. Or people having all their mechanical designs in
outdated and dying units and having a hard time changing this, even
though the direction is clear, so is the inevitability of the change,
and it costs more each year to stick with the dying crowd.


> Maybe it was but everyone's moral compass seems to be afected to some
> degree by money and fame.

I don't think that the reason why C became popular has much to do with
morals or fame. K+R wrote a tool that did what they needed, other people
started to use it because it also did what they needed (and apparently
better than the alternatives), then there were many enough people using
it that they standardized it, then the standard made it possible to
(relatively) safely invest more in it, and the rest we know.

Gerhard
--
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 Sat, 4 Jul 2009, Gerhard Fiedler 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.
>
> Besides, there usually is a reason why something is free. As there is no
> such thing as a free lunch, /somebody/ paid for it -- and had a reason
> to pay for it. And if something similar isn't free, it's usually because
> of the lack of such "somebodies" that pay for something to be free.
> Again, there is usually a reason.
>
> Also, when I started programming, neither the C compilers nor the Pascal
> compilers I used were free. IIRC, Turbo Pascal was among the least
> expensive ones, and that's what most people I knew used. They stopped
> using it, mainly because it was a one-vendor thing which didn't give it
> much of a future.

I remember that a BCPL compiler could be got for free before the PC became
available if you implemented the O-code interpreter for your machine
yourself. I remember one lecturer doing this for a CTL MOD 1.

Maybe the C and PASCAL compilers you used were not free but I'll bet you
probably knew someone that could have let you have an evaluation copy at
that time ;-) I'm convinced there were a great many evaluation copies
around at that time.

>
>
> >> Even if we accept all the above and understand C is required for some
> >> new projects only because it is already popular, what is missing is
> >> the outcry of users demanding something better.
> >
> > I've seem users "demanding" something better. I've even seen users
> > demanding to use better C compilers than the one currently being
> > used. My experience: it's like farting in a hurricane!
>
> I agree :)  Especially if there isn't a common idea of something better.
> Demanding may be efficient for kings; "normal" people need really to do
> something else to get somewhere.

You name it I've seen "'normal' people" people try it. When the "pointy
haired boss" has decided "you are going to do it this way" about the only
thing that's going to change his mind is a head transplant :-)

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