Searching \ for '[PIC] C syntax in assembler' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=c
Search entire site for: 'C syntax in assembler'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] C syntax in assembler'
2010\12\29@035833 by IVP

face picon face
Hi all,

compliments of the season

I'm converting some C to dsPIC assembly and need a little help,
as I know only a bit of C. How it's spelled for example

In the first part of the example below, it appears to be a simple
magnitude test. 'if diff is greater or equal to 0, byte = 0. If diff
is less than 0 then set byte,3 and negate diff'

***
if(diff >= 0)
    byte = 0;
else

{
    byte = 8;
    diff = - diff;
}
***

This bit here is where I think I'm stuck

Without any explicit 'elses', does this code execute each 'if', with
the parentheses being the 'elses' ? eg if 'if(diff >= tempstep)' is false,
then program flow jumps to tempstep >>= 1;shift #1

if(diff >= tempstep)
{
    byte |= 4;
    diff -= tempstep;
}

tempstep >>= 1;shift #1

if(diff >= tempstep)
{
    byte |= 2;
    diff -= tempstep;
}

tempstep >>= 1;shift #2

if(diff >= tempstep)
    byte |= 1;

diffq = step >> 3;

My interpretation -

if diff >= tempstep then (set byte,3 ,diff = diff - tempstep, rshft tempstep) else just rshft tempstep
if diff >= tempstep then (set byte,2 ,diff = diff - tempstep, rshft tempstep) else just rshft tempstep
if diff >= tempstep then (set byte,1 ,diffq = step/8) else just diffq = step/8

Correct ?

Joe

2010\12\29@050511 by cdb

flavicon
face
:: In the first part of the example below, it appears to be a simple
:: magnitude test. 'if diff is greater or equal to 0, byte = 0. If
:: diff
:: is less than 0 then set byte,3

:: {
::     byte = 8;
::     diff = - diff;
:: }
Hi Jinx,

contents of byte = decimal 8 - is that what you meant to type rather than bit 3 of byte?

:: Without any explicit 'elses', does this code execute each 'if',
:: with
:: the parentheses being the 'elses' ?

You confused me there with the word elses, but yes sort of, the first IF is tested, and if found to be false it will jump to -

:: tempstep >>= 1;shift #1

But if diff was equal to and greater than tempstep, you would have the IF statement and what is between the braces will be executed AS WELL as the tempstep code and so on down the list.

Colin
--
cdb, spam_OUTcolinTakeThisOuTspambtech-online.co.uk on 29/12/2010
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 


2010\12\29@055940 by IVP

face picon face
Colin,

> contents of byte = decimal 8 - is that what you meant to type rather
> than bit 3 of byte?

Actually, that would make sense if byte hadn't been cleared previously

> You confused me there with the word elses, but yes sort of, the first
> IF is tested, and if found to be false it will jump to -
>
> :: tempstep >>= 1;shift #1
>
> ..... and so on down the list.

Thanks much

Jo

2010\12\29@083214 by Olin Lathrop

face picon face
IVP wrote:
> if(diff >= 0)
>      byte = 0;
> else
>
> {
>      byte = 8;
>      diff = - diff;
> }

I'm no C whiz (I can just about spell it), but that looks really messed up
to me.  Hopefully someone that actually knows C will jump in, but doesn't
the ";" at the end of the second line end the IF statement?  If so, the ELSE
must be part of a outer IF statement not shown?

Unfortunately C encourages such messily written code.  Yucc.

Anyway, assuming 16 bit signed integers and the general case of DIFF and
BYTE not being in special (near) memory, the first two lines can be state in
ASM30 thusly:

   mov   #0, w1      ;get zero ready in case needed
   mov   diff, w0    ;get DIFF
   btss  w0, #15     ;DIFF < 0 ?
   mov   w1, byte    ;no, DIFF >= 0, clear BYTE to 0

Note that this code snippet trashes W0 and W1.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\29@085448 by PETER ONION

flavicon
face
----- Original Message ----

> From: Olin Lathrop <.....olin_piclistKILLspamspam@spam@embedinc.com>
> To: Microcontroller discussion list - Public. <piclistspamKILLspammit.edu>
> Sent: Wednesday, 29 December, 2010 13:33:10
> Subject: Re: [PIC] C syntax in assembler
>
> IVP wrote:
> > if(diff >= 0)
> >      byte =  0;
> > else
> >
> > {
> >      byte =  8;
> >      diff = - diff;
> > }
>
> I'm no C whiz (I  can just about spell it), but that looks really messed up
> to me.   Hopefully someone that actually knows C will jump in, but doesn't
> the ";" at  the end of the second line end the IF statement?  If so, the ELSE
> must  be part of a outer IF statement not shown?

No and No.

The ";" just terminates the "if true statement".
A quick google would have stopped you making all the wrong assumptions !
http://en.wikipedia.org/wiki/C_syntax#Control_structures

PeterO

2010\12\29@092909 by Olin Lathrop

face picon face
PETER ONION wrote:
>>> if(diff >= 0)
>>>      byte =  0;
>>> else
>>>
>>> {
>>>      byte =  8;
>>>      diff = - diff;
>>> }
>
> The ";" just terminates the "if true statement".

But if a semicolon doesn't end the IF statement, what does end it
unambiguously?  Or put another way, what if there was a outer IF not shown
above, and ELSE was meant to be part of it, not the IF shown.  How would you
then end the IF shown so that the ELSE would not be part of it?

For example:

 if (outer_condition)
     if (inner_condition) count=0; //TRUE case of outer IF
   else
     do_something();               //FALSE case of outer IF

How do you "end" the second IF so that the ELSE belongs to the first IF?  If
what you're saying above is true, then the only way to do this is to put the
second IF inside brackets?  I suppose that's at least consistant, but just
asking for easily made mistakes.  Worse, what I wrote above would not be
interpreted as intended, but would be perfectly legal and not generate any
compile error.

This is why it seemed logical that the ";" would end the inner IF.  But if
what you're saying is true (I expect it is, as I said, I'm no C whiz), it's
hard to imagine what was going thru K&R's minds when they designed the
syntax.

This would be yet another reason to religiously use brackets in IF
statements.  That's probably why I never bumped into this in real code.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\29@094459 by Isaac Marino Bavaresco

flavicon
face
Em 29/12/2010 12:30, Olin Lathrop escreveu:
> PETER ONION wrote:
>>>> if(diff >= 0)
>>>>      byte =  0;
>>>> else
>>>>
>>>> {
>>>>      byte =  8;
>>>>      diff = - diff;
>>>> }
>> The ";" just terminates the "if true statement".
> But if a semicolon doesn't end the IF statement, what does end it
> unambiguously?  Or put another way, what if there was a outer IF not shown
> above, and ELSE was meant to be part of it, not the IF shown.  How would you
> then end the IF shown so that the ELSE would not be part of it?


Then the entire inner 'if' must be enclosed inside curly braces.

 if (outer_condition)
     {
     if (inner_condition) count=0; //TRUE case of outer IF
     }
   else
     do_something();               //FALSE case of outer IF


{Quote hidden}

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com

2010\12\29@095233 by Oli Glaser

flavicon
face
On 29/12/2010 14:30, Olin Lathrop wrote:
> This would be yet another reason to religiously use brackets in IF
> statements.

This is exactly what I do to prevent confusion.

>   That's probably why I never bumped into this in real code.

<yawn...>

2010\12\29@100145 by PETER ONION

flavicon
face
----- Original Message ----


>Or put another way, what if  there was a outer IF not shown
> above, and ELSE was meant to be part of it,  not the IF shown.  How would you
> then end the IF shown so that the ELSE  would not be part of it?
>
> For example:
>
>   if  (outer_condition)
>       if (inner_condition) count=0; //TRUE  case of outer IF
>     else
>        do_something();               //FALSE case of  outer IF

>From the link I gave you:

"An else always matches the nearest previous unmatched if; braces may be used to override this when necessary, or for clarity."

> How do you "end" the second IF so that the ELSE belongs to the  first IF?  
It's not really a problem with the second IF but with your lack of understanding of what constitutes the "true statement" of the first IF.

> if what you're saying above is true, then the only way to do  this is to put
>the
> second IF inside brackets?  
Yes, that's exactly right.

To get the behaviour you want you need this:

if(outer_condition)
{
   if(Inner_conditional) count = 0;
}
else
 do_someting();


> I suppose that's at least  consistant, but just
> asking for easily made mistakes.

Not if you know what you are doing.  :-)

>  Worse, what I  wrote above would not be
> interpreted as intended, but would be perfectly  legal and not generate any
> compile error.

Indeed, but who's fault is that ?  You wrote valid C and that's really all the compiler can check for.  If your C code doesn't
do what you expected it to do then it's because you don't understand the C syntax and that's not the compiler's fault ! ;-)

> This is why it seemed  logical that the ";" would end the inner IF.

It's not logical to an experienced C coder :-)

> But if
> what you're saying  is true (I expect it is, as I said, I'm no C whiz), it's
> hard to imagine what  was going thru K&R's minds when they designed the
> syntax.
>
> This  would be yet another reason to religiously use brackets in  IF
> statements.  That's probably why I never bumped into this in real  code.

I often use extra brackets and my trick is to type all the brackets and semicolons first, so that in your case above I would type this first:

if()
{
      if()   ;
}
else
{
;
}

Then I go back and fill in the statements and remove any unneeded pairs of brackets.  Use of a consistent layout style also helps avoid problems.
PeterO

2010\12\29@103951 by Olin Lathrop

face picon face
PETER ONION wrote:
>>  Worse, what I  wrote above would not be
>> interpreted as intended, but would be perfectly  legal and not
>> generate any compile error.
>
> Indeed, but who's fault is that ?  You wrote valid C and that's
> really all the compiler can check for.  If your C code doesn't
> do what you expected it to do then it's because you don't understand
> the C syntax and that's not the compiler's fault ! ;-)

It's not about "fault", and in any case it can't be the compiler's since
it's just following the rules of the language.  Of course it's on the
programmer to know the syntax of the language, but there is also good and
bad syntax design.

In this case the syntax allows a easily made error to still result in legal
code but to not be interpreted as intended.  Programmers will always come up
with more clever errors than a language designer can and should account for,
but a measure of good language design is how much common and
should-be-anticipated errors get caught as illegal syntax.  A great example
is the really irresponsible C-ism "if (i=1)...".  While the error is
technically the programmers, the syntax rules are just asking for humans to
make that mistake.

In these two cases at least, Pascal gets it a lot more right than C.  In
Pascal:

 if outer_condition then
     if inner_condition then count := 1;
   else
     ...

Would generate a syntax error because the ";" ends the IF statement and ELSE
therefore is not valid there.

In the second case, the assignment operator is ":=" whereas "=" is a
statement of equality:

 if i = 1 then ...

does exactly what most people reading it would think.  If you actually wrote

 if i := 1 then ...

then you'd get a compile error since a assignment statement isn't allowed as
the condition expression of a IF statement.

Language design *does* matter.  Unfortunately C is badly designed but so
many people have gotten used to it they have become blind to the problems.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\29@110505 by Byron Jeff

flavicon
face
On Wed, Dec 29, 2010 at 08:33:10AM -0500, Olin Lathrop wrote:
> IVP wrote:
> > if(diff >= 0)
> >      byte = 0;
> > else
> >
> > {
> >      byte = 8;
> >      diff = - diff;
> > }
>
> I'm no C whiz (I can just about spell it), but that looks really messed up
> to me.  Hopefully someone that actually knows C will jump in, but doesn't
> the ";" at the end of the second line end the IF statement?
Nope. It simply terminates the statement byte = 0;

I always hated the fact that the braces were not required even when the
body of a control statement consisted of a single statement. The
inconsistency of making it optional is a bad idea.

> If so, the ELSE must be part of a outer IF statement not shown?

Nope. It's attached to that if.

>
> Unfortunately C encourages such messily written code.  Yucc.

Agreed. When I wrote my own language, I put in an explicit ENDIF that made
it very clear. In this example the else is attached:

if (diff >= 0)
  byte = 0
else
  byte = 8
  diff = -diff
endif

In the next example the else is attached to some other outer if:

  if (diff >= 0)
     byte = 0
  endif

else
  byte = 8
  diff = -diff
endif

It completely eliminates the confusion by putting a clear marker of the end
of the if statement. And it was always required, even if the body only
consisted of a single statement.


BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2010\12\29@111010 by Kerry Wentworth

flavicon
face
Unix was written in C.  Lisa was written in Pascal.

Knock Knock
Who's there?
(long pause)
Lisa!

If you like Pascal, go ahead and use it.  I prefer C.  That filter we discussed a while back?  I implemented my version, averaging 10 frequency samples, in C (CCS) on a 16F636.  Took about 10 minutes.

set_timer1(0);
TMR1ON=1;
delay_ms(10);
TMR1ON=0;
val=get_timer1();
total+=val;
total-=filt;
filt=total/10;

Kerry


Olin Lathrop wrote:
{Quote hidden}

-- Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.289 / Virus Database: 267.11.13 - Release Date: 10/6/05

2010\12\29@111113 by Nathan Nottingham

picon face

On Dec 29, 2010, at 07:30 AM, Olin Lathrop wrote:

> PETER ONION wrote:
>>>> if(diff >= 0)
>>>>     byte =  0;
>>>> else
>>>>
>>>> {
>>>>     byte =  8;
>>>>     diff = - diff;
>>>> }
>>
>> The ";" just terminates the "if true statement".
>
> But if a semicolon doesn't end the IF statement, what does end it
> unambiguously?  Or put another way, what if there was a outer IF not shown
> above, and ELSE was meant to be part of it, not the IF shown.  How would you
> then end the IF shown so that the ELSE would not be part of it?
>
Semicolons do not terminate an if statement.  In C, if statements will execute a single block of code following the if and the else (note: 'else if' statements just build on the above method).  The single block of code in the above is considered to be the line following the if and the code with the { } following the else.

An un-compiliable example:

   if(i >= 0)
       byte = 0;   //executes on condition
       byte++;     //always runs
   else            //syntax error, HAL is not pleased
   {
       byte = 99;
   }

If this could be run, line 2 is executed if i >= 0 is true.  Line 3 is always executed (note the nesting makes this ambiguous).  Then line 4, would be an orphaned else with no preceding if and the code will not compile.

If the programmer intents to execute what most of us see when we look at the above, the block to execute following the if needs to be enclosed:

   if(i >= 0)     {
       byte = 0;
       byte++;
   }
   else
   {
       byte = 99;
   }

2010\12\29@111705 by Byron Jeff

flavicon
face
On Wed, Dec 29, 2010 at 09:30:05AM -0500, Olin Lathrop wrote:
> PETER ONION wrote:
> >>> if(diff >= 0)
> >>>      byte =  0;
> >>> else
> >>>
> >>> {
> >>>      byte =  8;
> >>>      diff = - diff;
> >>> }
> >
> > The ";" just terminates the "if true statement".
>
> But if a semicolon doesn't end the IF statement, what does end it
> unambiguously?

Nothing. The ambiguity is resolved by the rule "closest open if statement".
You have to expliticly use braces to shield an inner if statement from an
outer else. Two examples:

if (outer)
  if (inner)
     oneline = 0;

 else // Placed "ambiguously" on purpose
   elseval = 1

Since there are no braces to direct assignment, the else is attached to the
closest open if statement, which in this case is the inner one.

It's always better to be explicit about it. Here's how braces can be used
to force the else to be attached to the outer if:

if (outer) { // Forcing brace
  if (inner) { // Brace not required, but I always put it anyway
     oneline = 0;
  } // This does not close the inner if, simply terminates the if part
} // Forcing brace. This does close the inner if because it closes the if
 // part of the outer if. So we are in outer if space at this point.
else { // This else is attached to the outer if
  elseval = 1;
}


{Quote hidden}

See above.

> If
> what you're saying above is true, then the only way to do this is to put the
> second IF inside brackets?  I suppose that's at least consistant, but just
> asking for easily made mistakes.  Worse, what I wrote above would not be
> interpreted as intended, but would be perfectly legal and not generate any
> compile error.

Exactly. But unfortunately both by custom and by standard, C is set in
stone and cannot be changed at this point.
>
> This is why it seemed logical that the ";" would end the inner IF.  But if
> what you're saying is true (I expect it is, as I said, I'm no C whiz), it's
> hard to imagine what was going thru K&R's minds when they designed the
> syntax.
>
Kernighan's primary concern at the time was compactness of expression. So
making braces optional and having a default rule generated the most compact
source.

As I said in my other post, I use and explicit ENDIF construct, which
completely disambiguates the situation.

> This would be yet another reason to religiously use brackets in IF
> statements.  That's probably why I never bumped into this in real code.

I do the same. Braces all the time, even when not required.

BAJ

-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2010\12\29@111949 by Olin Lathrop

face picon face
Kerry Wentworth wrote:
> Unix was written in C.  Lisa was written in Pascal.
>
> Knock Knock
> Who's there?
> (long pause)
> Lisa!

And you think this is somehow related to the relative merits of the syntax
of these two languages!?

> If you like Pascal, go ahead and use it.  I prefer C.

Did you even bother to read the points that were made.  They weren't about
liking anything, but about syntax design.  Lots of people prefer C, probably
because they are used to it.  That, however, has absolutely no bearing on
whether its syntax design was good or not or whether there are better
designs out there.

> That filter we
> discussed a while back?  I implemented my version, averaging 10
> frequency samples, in C (CCS) on a 16F636.  Took about 10 minutes.

And that is supposed to be a argument for what exactly?

Your whole post is seems a knee jerk emotional response since it's so
unrelated to what was actually being discussed.  I'm sorry your C-ness is
somehow threatened by mere discussion of syntax, but that's really of no
interest to anyone else.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\29@112508 by PETER ONION

flavicon
face




----- Original Message ----
> From: Olin Lathrop <.....olin_piclistKILLspamspam.....embedinc.com>
> To: Microcontroller discussion list - Public. <EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu>
> Sent: Wednesday, 29 December, 2010 15:40:47
> Subject: Re: [PIC] C syntax in assembler
>  
> Language design *does* matter.  Unfortunately C is  badly designed but so
> many people have gotten used to it they have become  blind to the  problems.
>
They are not "blind to the problems" they are "competent C programmers".  They understand the language's limitations and don't try blame the tools.

Arguments about C's design often fail to recognise that the bulk of C was designed nearly 40 years ago.
Arguing that C doesn't match up to modern design ideas is ultimately a pointless exercise.

If C was as bad as some try to make out it wouldn't have survived this long..  
PeterO

2010\12\29@115246 by Byron Jeff

flavicon
face

On Wed, Dec 29, 2010 at 10:40:47AM -0500, Olin Lathrop wrote:
> PETER ONION wrote:
> >>  Worse, what I  wrote above would not be
> >> interpreted as intended, but would be perfectly  legal and not
> >> generate any compile error.
> >
> > Indeed, but who's fault is that ?  You wrote valid C and that's
> > really all the compiler can check for.  If your C code doesn't
> > do what you expected it to do then it's because you don't understand
> > the C syntax and that's not the compiler's fault ! ;-)
>
> It's not about "fault", and in any case it can't be the compiler's since
> it's just following the rules of the language.  Of course it's on the
> programmer to know the syntax of the language, but there is also good and
> bad syntax design.

Agreed. Ambiguous syntax creates an environment for the creation of bugs.
But when you had machines that cost in the hundreds of thousands of dollars
and had less RAM and disk than even a single PIC does today, it's somewhat
understandable as to why they made the choices that they made at the time.

>
> In this case the syntax allows a easily made error to still result in legal
> code but to not be interpreted as intended.  Programmers will always come up
> with more clever errors than a language designer can and should account for,
> but a measure of good language design is how much common and
> should-be-anticipated errors get caught as illegal syntax.  A great example
> is the really irresponsible C-ism "if (i=1)...".  While the error is
> technically the programmers, the syntax rules are just asking for humans to
> make that mistake.

Which is why most compilers will at least generate a warning and ask that
you double paren that assignment if you really want it.

{Quote hidden}

I kind of like C's ability to use assignment as an expression. Again it
does facilitate a compactness of expression that other languages do not
have the ability to accomplish. The problem is having a way to disambiguate
assignment from comparison when both are legal. I find the warning and the
double parens sufficient. For example this code with the GCC compiler:

#include <stdio.h>

int main()
{
  int i;

  if (i=1) {
     printf("true\n");
  }
  return 0;
}

While perfectly legal, will generate the following warning if the all
warnings flag is on:

dp.c: In function ‘main’:
dp.c:7: warning: suggest parentheses around assignment used as truth value

And if you use the double parens as such:

#include <stdio.h>

int main()
{
  int i;

  if ((i=1)) {
     printf("true\n");
  }
  return 0;
}

The warning disappears. It's not a perfect solution, but sometimes to gain
flexibility and creativity, there has to be a middle ground.

>
> Language design *does* matter.  Unfortunately C is badly designed but so
> many people have gotten used to it they have become blind to the problems.

It certainly has its issues. But I disagree about programmers being blind
to them. I think they like the benefits of some of these constructs and so
are willing to live with the consequences.

BTW you didn't even get to the one that just sticks in my craw:

The default drop through action of cases in the switch statement.

Talk about driving me crazy. The real screwup is by choosing the wrong
default action, virtually every swich generates more source code than if
they had selected what everyone expects and uses the vast majority of the
time. A switch is a selector:

choice = 1;
switch (choice) {
  case 1: printf("1 was picked\n");
  case 2: printf("2 was picked\n");
  case 3: printf("3 was picked\n");
  default: printf("other was picked\n");
}

Now as a selector, since 1 was selected, there's no good reason to execute
code for the other choices. So the default should be that when you execute
the code for a case, when you reach the end of that case, then you leave
the construct. The code above should print

1 was picked

and leave.

But in a baffling choice, drop through was selected as the default. So this
code actually prints:

1 was picked
2 was picked
3 was picked
other was picked

which is totally ass-backwards since the point of the construct is to
select an option, which presumes mutual exclusion to the other options.

Now of course the behavior can be short circuited with the use of a break
statement:


choice = 1;
switch (choice) {
  case 1: printf("1 was picked\n");
          break;
  case 2: printf("2 was picked\n");
          break;
  case 3: printf("3 was picked\n");
          break;
  default: printf("other was picked\n");
          break; // Unneccessary but often put in for consistency.
}

But to me this defeats the purpose of compactness of expression. It's
completely counterintuitive. The original construct above should have the
default behavior of running the code for a single case, then leaving. Then
the vast majority of the code will be smaller and make a lot more since.

The only argument that holds water is that since ranges are not allowed,
the default fall through allows multiple cases to share the same code:

choice = 1;
switch (choice) {
  case 1:
  case 2:
  case 3: printf("1,2, or 3 was picked\n");
          break;
  default: printf("other was picked\n");
          break; // Unneccessary but often put in for consistency.
}

But to make it the default behavior for that reason seems silly to me.

BTW I would allow for fallthrough, but simply not make it the default. It
would have been simple to have fallthrough occur with the use of the
continue statement. In my view the last snippet should be written as:


choice = 1;
switch (choice) {
  case 1: continue;
  case 2: continue;
  case 3: printf("1,2, or 3 was picked\n");
          break;
  default: printf("other was picked\n");
          break; // Unneccessary but often put in for consistency.
}

Couple that with the default behavior of execute one case then leave
(unless a continue is at the end of the case) and I'd be a much happier
camper.

It was a poor, poor choice. It's neck and neck with the differences between
array and structure behavior as the worst design choices IMHO.

BAJ

--
Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjeff

2010\12\29@120959 by M.L.

flavicon
face

On Wed, Dec 29, 2010 at 12:07 PM, Byron Jeff <byronjeffspamspam_OUTmail.clayton.edu> wrote:
> BTW I would allow for fallthrough, but simply not make it the default. It
> would have been simple to have fallthrough occur with the use of the
> continue statement. In my view the last snippet should be written as:
>
>
> choice = 1;
> switch (choice) {
>   case 1: continue;
>   case 2: continue;
>   case 3: printf("1,2, or 3 was picked\n");
>           break;
>   default: printf("other was picked\n");
>           break; // Unneccessary but often put in for consistency.
> }
>

I'm not sure if you've thought this through fully. The 'continue'
statement is for going to the next iteration of a loop. Adding it's
use in a case statement would make ambiguous cases (no pun intended)
such as:

while(inbyte = getbyte() )
{
 switch(inbyte)
   {
   case 1:
     ....
     continue; // Go to next case or next iteration of loop?
   case 2:
      ...
    };
}


--
Martin K.

2010\12\29@121825 by Olin Lathrop

face picon face
PETER ONION wrote:
> They are not "blind to the problems" they are "competent C
> programmers".

Yes you can eventually learn not to stub your toe on a nail sticking up from
the middle of the floor, but that doesn't change the fact that the nail
sticking up is a bad idea.  The problem with too many C programmers is that
they've taken the nail for granted and no longer realize the world could be
better.

> Arguments about C's design often fail to recognise that the bulk of C
> was designed nearly 40 years ago.

There were other syntaxes already known at the time that dealt better with
likely human errors.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\29@123840 by Byron Jeff

flavicon
face
On Wed, Dec 29, 2010 at 12:09:38PM -0500, M.L. wrote:
{Quote hidden}

I have thought this through fully. In C break and continue statements
affect the closest enclosing control structure that statement is valid for.

In you example above, with my modifications, it would go to the next case
and is completely unambiguous. Consider the perfectly valid C construct:


while(inbyte = getbyte() )
{
 switch(inbyte)
   {
   case 1:
     ....
     break; // leave switch or leave loop?
   case 2:
      ...
    };
}

There's no ambiguity. Since break affects switches, and this break is in a
currently open switch, it affects the switch and not the while loop.

Of course all of this is a moot design discussion since none of these
changes can be made in the existing language precisely because it'll break
10 billion lines of already generated code. I was just complaining that K&R
made a poor choice by choosing to make the minority opinion the default.

BAJ

-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2010\12\29@124627 by Olin Lathrop

face picon face
Byron Jeff wrote:
> I kind of like C's ability to use assignment as an expression.

Hmm.  I rather doubt there is any real efficiency gained from that by
reasonably written compilers.

> Again it
> does facilitate a compactness of expression that other languages do
> not have the ability to accomplish.

That may have been K&R's intent, and perhaps there was some limited reason
for it back then, but there is certainly little reason for it now.  Clarity
is far more important than compactness, and I think should have been back
then too.  I mostly care about compactness only as it enhances clarity.  Go
too far and it detracts from clarity.

> BTW you didn't even get to the one that just sticks in my craw:
>
> The default drop through action of cases in the switch statement.

Yeah, that's another good one.  I totally agree the default should be to end
the switch, not fall thru to the next case.  The C SWITCH is just a computed
GOTO, not a real selection of multiple cases as the syntax would lead a
casual observer to believe.  If they had named it MULTIJUMP or something, it
wouldn't bother me so much, but then I'd still want a real multi-case
statement.

By the way, the Pascal CASE statement does work as you describe.  For
example:

 choice := 1;
 case choice of
1:  writeln ('1 was picked');
3:  writeln ('2 was picked');
3:  writeln ('3 was picked');
otherwise
   writeln ('Other was picked');
   end;

would only result in "1 was picked" to be written.  You don't have to be a
Pascal whiz to have a pretty good idea what the above code does.

{Quote hidden}

Pascal gets around it this way:

 case choice of
1, 2, 3: writeln ('1, 2, or 3 was picked');
otherwise
   writeln ('Other was picked');
   end;

In other words, you can't put a bunch of cases in a row and fall thru, but
you can give each case multiple target values.  I think that addresses your
concern adequately enough.

> switch (choice) {
>    case 1: continue;
>    case 2: continue;
>    case 3: printf("1,2, or 3 was picked\n");
>            break;
>    default: printf("other was picked\n");
>            break; // Unneccessary but often put in for consistency.
> }

Something like that, although as Martin pointed out, CONTINUE already has
another meaning.  I would be fine with this if a different and new keyword
were used, like NEXTCASE for example.

> Byron A. Jeff
> Department Chair: IT/CS/CNET
> College of Information and Mathematical Sciences
> Clayton State University

Hey, when did that happen?  Congratulations!  Is that the same place you
were before, or did you have to go elsewhere to get promoted?  Last I
remember (probably a long time ago since my brain usually tunes out email
signatures) you were someplace in Georgia.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\29@131245 by Byron Jeff

flavicon
face
On Wed, Dec 29, 2010 at 12:47:22PM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > I kind of like C's ability to use assignment as an expression.
>
> Hmm.  I rather doubt there is any real efficiency gained from that by
> reasonably written compilers.

>
> > Again it
> > does facilitate a compactness of expression that other languages do
> > not have the ability to accomplish.
>
> That may have been K&R's intent, and perhaps there was some limited reason
> for it back then, but there is certainly little reason for it now.  Clarity
> is far more important than compactness, and I think should have been back
> then too.  I mostly care about compactness only as it enhances clarity.  Go
> too far and it detracts from clarity.

C certainly has the ability to bash clarity down into the ground if a
programmer so decides to want to do it. But there are times when clarity
and compactness do not have to be at odds. Even something as simple as:

a = b = c = d = 0;

is perfectly readable yet compact. But it's only doable if assignment is an
expression, and not a statement.

{Quote hidden}

I know. I learned the case statement first. That's one reason why the C
switch always drove me nuts.

{Quote hidden}

Agreed. But as you pointed out, C's switch is a computed goto and has no
facility to do that.

{Quote hidden}

It's probably my C bias leaking through. Since break was multipurposed in
loops and switches, it seems natural to me that continue could have done
the same.

>
> > Byron A. Jeff
> > Department Chair: IT/CS/CNET
> > College of Information and Mathematical Sciences
> > Clayton State University
>
> Hey, when did that happen?  Congratulations!  Is that the same place you
> were before, or did you have to go elsewhere to get promoted?

Thanks.

Same place. Tenure, promotion, and put into administration all at the same
time.

>  Last I
> remember (probably a long time ago since my brain usually tunes out email
> signatures) you were someplace in Georgia.

This happened about 6 months ago. I've been out of the loop busy learning
the new job. Also we had a slight E-mail change and my old registered
E-mail wasn't available for list postings. I finally got around to
reregistering. So I plan to drop in an out with postings though I lurk
regularly.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2010\12\29@142718 by Steve Willoughby

flavicon
face
On 29-Dec-10 10:27, Byron Jeff wrote:
> C certainly has the ability to bash clarity down into the ground if a
> programmer so decides to want to do it. But there are times when clarity
> and compactness do not have to be at odds. Even something as simple as:
>
> a = b = c = d = 0;
>
> is perfectly readable yet compact. But it's only doable if assignment is an
> expression, and not a statement.

Not necessarily.  Python, for example, disallows assignment in expressions but does allow assignments to stack up like that, as part of the assignment statement syntax.

As a long-time C programmer, it initially really irritated me (and still occasionally does) that Python doesn't allow assignment in expressions, but I do see the point in favor of clarity (which is the stated reason for the restriction).

-- Steve Willoughby / KILLspamsteveKILLspamspamalchemy.com
"A ship in harbor is safe, but that is not what ships are built for."
PGP Fingerprint 48A3 2621 E72C 31D9 2928 2E8F 6506 DB29 54F7 0F5

2010\12\29@152947 by alan.b.pearce

face picon face
> In this case the syntax allows a easily made error to still result in
> legal code but to not be interpreted as intended.

Isn't this why Lint was invented? I would guess that this exact possible error has made it into the PC-Lint error of the month in their adverts.
-- Scanned by iCritical.

2010\12\29@160524 by Olin Lathrop

face picon face
alan.b.pearce@stfc.ac.uk wrote:
>> In this case the syntax allows a easily made error to still result in
>> legal code but to not be interpreted as intended.
>
> Isn't this why Lint was invented?

And Lint is only necessary due to unfortunate syntax design choices.  In
better designed languages, the things that Lint catches aren't legal in the
first place.  For how many other languages have people felt the need to
create Lint-like tools?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\29@174131 by Wouter van Ooijen

face picon face
> And Lint is only necessary due to unfortunate syntax design choices.  In
> better designed languages, the things that Lint catches aren't legal in the
> first place.  For how many other languages have people felt the need to
> create Lint-like tools?

Every compiler that has warnings has an implicit lint-like functionality.

C has a lot of unfortunate syntax choices. On the other hand, Pascal, Modula and Ada made much better choices, yet we are (almost) all using C (or C++, javascript, java, C#, or some other C derivate). Why? I guess C must have done something right, but I am not sure what it is.

Maybe Python will decide the battle for against the curly braces. With TCL and Perl in its group it sure has had very little resistance so far in the battle for reasonable syntax, let' see how well it does in the nock-out phase :)

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\12\29@183555 by Michael Watterson

face picon face
On 29/12/2010 22:41, Wouter van Ooijen wrote:
>> And Lint is only necessary due to unfortunate syntax design choices.  In
>> better designed languages, the things that Lint catches aren't legal in the
>> first place.  For how many other languages have people felt the need to
>> create Lint-like tools?
> Every compiler that has warnings has an implicit lint-like functionality.
>
> C has a lot of unfortunate syntax choices. On the other hand, Pascal,
> Modula and Ada made much better choices, yet we are (almost) all using C
> (or C++, javascript, java, C#, or some other C derivate). Why? I guess C
> must have done something right, but I am not sure what it is.

Purely because C was language of Choice for UNIX, BSD, MSDOS, Windows, Linux.

Popularity rather than anything.
Originally it was also that as essentially a Machine Independent Macro Assembler (hence dependency  on #defines and preprocessor and "make files") it was easy to port and simple.

Then C had all the Libraries ...

It was longer before other languages  had production quality compilers.

Pascal and  BASIC only meant originally for teaching (BASIC originally a cut down ForTran)

Modula-2 was too late

C++ was crippled by backward compatibility to C. Most C++ programs are too much like C programs. The C++ designer didn't want this. It was foisted on C++ by AT&T.

Of course AT&T attitude to ownership of UNIX and the University involvement is directly responsible for Free BSD, GNU, Linux and the rest of the last 30+ years of FOSS wheel re-inventing.


So sooner we get away from C and C like C++ programs the better. Most Security flaws and bugs are due to strings & Array bounds handling and traditional C string/array libraries.

A compiler can't easily check the sanity of a printf either.

I have used C++ since about 1987 and C from 1988. This is why I like JALV2 on PIC, and C# or VB6 on Windows and used Modula-2 on DOS

2010\12\29@184524 by Olin Lathrop

face picon face
Wouter van Ooijen wrote:
> Why? I guess C must have done something right, but I am not sure what
> it is.

Market acceptance is based on a number of factors, with technical
superiority not usually near the top of the list.

In think C got popular for various reasons, some having to do with history
and luck.  One technical point in its favor was that it was relatively easy
to write a compiler for.  The syntax changes I would have liked wouldn't
have made it harder though I think.

In my opinion, another factor is specifically because it is such a "bad"
language.  Especially in the early 1980s when C was at its steepest rise,
there was a lot of "I don't need no stink'n type checking" attitude and the
like.  It's relatively easy to do something simple quickly in C without
having to learn a lot and do a lot of them silly declaration thingies.  So C
had a initial appeal to bad or lazy programmers, and once it got critical
mass was hard to stop.  Unfortunately most programmers are bad, so few were
trying to stop it.

Never underestimate the power of morons in large numbers.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\30@003334 by Sergey Dryga

flavicon
face
Olin Lathrop <olin_piclist <at> embedinc.com> writes:

>
> Wouter van Ooijen wrote:
> > Why? I guess C must have done something right, but I am not sure what
> > it is.
> <SNIP>

> In my opinion, another factor is specifically because it is such a "bad"
> language.  
I would strongly disagree with this statement.  C is not "bad" in general, it is
only bad when applied incorrectly.  Like any other tool, C is better suited for
some applications.  The same way, there is no universally "good" language. Gotta use right tool for the job.  Most people would not write Windows GUI app
in assembler, the same way using java to write firmware for PIC16 is probably
not a good idea, at least in majority of applications.
Sergey Dryga
http://www.beaglerobotics.com

2010\12\30@035436 by Wouter van Ooijen

face picon face
> I would strongly disagree with this statement.  C is not "bad" in general, it is
> only bad when applied incorrectly.

Of course C is not bad in the sense of evil (= can only be used for the worse) but IMHO it is undoubtedly bad in the sense that some small changes could reduce the potential for disaster enormously. Go read Stroustrup for lots of suggestions. This is not the same as saying that the original authors did a bad job, rather an observation about how the computer community as a whole works.

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\12\30@073048 by Walter Banks

picon face


Byron Jeff wrote:

> I always hated the fact that the braces were not required even when the
> body of a control statement consisted of a single statement. The
> inconsistency of making it optional is a bad idea.

It actually is one area where C is very consistent. Statements in C do
not have braces but any statement in C is made into a compound
statement with braces.

if (condition)
  statement_if
else
 statement_else

statement_if can be a single statement which ends in ";" or a
compound statement containing one or more statements
{ statement1;  statement2; . . . .  }

Braces have some other characteristics that can be
usefull

{ char a,b,c; statement1; statement2;... }

the declaration of the local variables chars a,b,c  remains
until the "}" and the space can be reused for other local variables.
Nesting braces provides local control over variable scope a
feature that is almost uniquely C.

Braces in C keep thoughts in one place unlike most languages
that use ";" as a statement continuation.

I wish that pascal had braces and statement locals and C had
pascal's local functions.

All the best of the season,

w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com



2010\12\30@094617 by Olin Lathrop

face picon face
Walter Banks wrote:
> I wish that pascal had braces and statement locals and C had
> pascal's local functions.

Pascal has BEGIN/END, which is pretty much the same as C braces.  A
BEGIN/END block is a compound statement that is viewed as a single statement
outside the block.

I'm not sure what you mean by "statement locals".  If you mean temporary
variables only within the scope of a specific block of code, as apposed to a
whole routine, then I don't know of anything similar in Pascal.  That is a
reasonable idea that is embodied in C (Wow, who'd have thought!).

In my source to source translator, there is a significant section of code in
the C back end to deal with local functions.  I emulate them by using global
functions and explicitly passing any accessed local state down to the
function.

This can get messy with nesting.  Let's say routine A calls local routine B,
which calls its own local routine C.  C may access a local variable of A, so
that variable has to be passed to B just so B can pass it to C when these
local routines are emulated with global routines.  My translator does
multiple passes of pushing call arguments up the chain until no changes are
made in a pass.  The result is not pretty, but it works for the C output
language.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\12\30@103245 by Walter Banks

picon face


Olin Lathrop wrote:

> Walter Banks wrote:
> > I wish that pascal had braces and statement locals and C had
> > pascal's local functions.
>
> Pascal has BEGIN/END, which is pretty much the same as C braces.  A
> BEGIN/END block is a compound statement that is viewed as a single statement
> outside the block.

The major difference is pascal uses a ";" as a statement separator in a
a compound statement.

begin
 statement
end;

begin
 statement ;
 statement1
end

In C ";" terminates a statement



> temporary
> variables only within the scope of a specific block of code, as apposed to a
> whole routine, then I don't know of anything similar in Pascal.  That is a
> reasonable idea that is embodied in C (Wow, who'd have thought!).

This is a very good idea, I agree

{Quote hidden}

This has always been the argument used in WG14 meetings that scope
resolution is complex for nested functions. The problem has several solutions
including the one you describe. It is actually no more complex than resolving
temporary variables in nested brace blocks. Pascal local functions have the
same implementation issues. Nested functions are one feature that I wish C
had.


All the best of the season,

Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com





2010\12\30@162819 by William \Chops\ Westfield

face picon face

On Dec 29, 2010, at 3:35 PM, Michael Watterson wrote:

>> yet we are (almost) all using C ...  Why? I guess C
>> must have done something right, but I am not sure what it is.
>
> Purely because C was language of Choice for UNIX, BSD, MSDOS,  
> Windows, Linux.
>
> Popularity rather than anything.

Your memory doesn't match my memory.  "popularity" would have meant  that we'd all be programming in Fortran or Cobol.  Unix wasn't  generally available.  MSDOS C compilers lagged other languages by  several years.  Early C compilers were pretty sucky.  Borland's Pascal  was pretty good pre-dated their C compiler by quite a bit.

What happened to Algol and PL/1 ?  Both languages featuring "modern"  concepts and with large amounts of vendor support?  Bliss?


> Then C had all the Libraries ...

C didn't have libraries to start with.  Sometimes I think its success  was due to NOT having libraries.  There were languages from those days  that had "all the libraries you'll ever need" built into the  language.  OS specific, of course.  And meaning that extensibility  beyond that was more difficult.   And portability was poor.  There was  a whole slew of mainframe and minicomputers that supported a bunch of  languages generally NOT including C (unless you were a university and  could get unix.)  It can be very enlightening (and painful) to look at  code from the early 90s when massive amounts of conditional  compilation were needed if you wanted your app to run on windows, sun,  hp, and AT&T unix...

Portability is probably why C won.  Not just portability of the code  itself.  Compilers used to be essentially sales tools for multi- million dollar mainframes.  The big vendors spent LOTS of effort  making highly optimized Fortran and Cobol compilers, plus Algol and  Basic for schools, plus proprietary (?) languages to fix everything  (PL/1)  This "model" was not portable to the new world of "personal"  computers.  IBMs compilers were barely portable to an environment that  supported interactivity...  Many compilers weren't designed to be  portable to "small" or embedded computing environments.  Look at the  number of currently "popular" languages that are not very suitable for  small environments!

Ada is a fine example of a language definition aimed at the old model  of computer development/deployment, finished just in time for that  model to be pretty much broken.  "Sure IBM and DEC will spend millions  implementing these compilers.  They'll HAVE to!!"  Right.

Of course, we now have C# and Java; modern examples of major vendor- implemented languages.
I'd class C# as making the same environment-specific mistakes as the  early efforts


> It was longer before other languages  had production quality  
> compilers.

No.


> Pascal and  BASIC only meant originally for teaching

Yeah; I think a lot of the blame can be based on the groups that  developed "teaching languages" without paying enough attention to what  it would take to make the language generally useful in the real world.


> Of course AT&T attitude to ownership of UNIX and the University
> involvement is directly responsible for Free BSD, GNU, Linux and the
> rest of the last 30+ years of FOSS wheel re-inventing.

FOSS definitely helped C a lot, even before it was called that.  First  there was the portable C compiler, which lasted through the late  1980s.  Then there was gcc.

BillW

2010\12\30@165905 by Carl Denk

flavicon
face
And lets not forget MAD (Michigan Algorithm Decoder) running on IBM 709 (vacuum tubes) and 7090 (solid state) in the early 1960's. It helped a lot to have Alfred E. Newman's picture on the cover. :)  Then in the mid 1970's there was Basic running on a Univac 1108.
> FOSS definitely helped C a lot, even before it was called that.  First
> there was the portable C compiler, which lasted through the late
> 1980s.  Then there was gcc.
>
> BillW
>
>

2010\12\30@205830 by Sergey Dryga

flavicon
face
Wouter van Ooijen <wouter <at> voti.nl> writes:

>
> > I would strongly disagree with this statement.  C is not "bad" in general,
it is
> > only bad when applied incorrectly.
>
> Of course C is not bad in the sense of evil (= can only be used for the
> worse) but IMHO it is undoubtedly bad in the sense that some small
> changes could reduce the potential for disaster enormously. Go read
> Stroustrup for lots of suggestions. This is not the same as saying that
> the original authors did a bad job, rather an observation about how the
> computer community as a whole works.
>
Agree, any language, including C, can be improved.  C is definitely a product of
its time and since computer sciences and applications have advanced, the
original C is not adequate any more.  So it has evolved a bit.  
If one follows all suggestions by Stroustrup, would we not get C++?  
My comment was actually targeted to the specific discussions on this list as to
which language is best.  It seems like C vs assembler vs Jal vs whatever
discussions ignite very often and I wanted to point out that there is a right
tool for every specific applcation.
Sergey Dryga

http://beaglerobotics.com

2010\12\30@213500 by Kerry Wentworth

flavicon
face
Theoretically, yes.  Nothing is perfect.  Many programmers like to #define stuff to make the language more palatable, like:

#define FOREVER for(;;)

BUT, to change something like case fallthrough, or how else attaches to ifs would be totally unacceptable, no matter how much it would 'improve' C.  You could make a new language that is exactly like C except for the things you'd like improved and call it something else, like ANSI C, C++, C--, C#, Cflat, Cspotrun, or even D.  But 'improving' C by making it incompatible with C would be like MicroChip 'improving' the pinout of the 16F887 but still selling it as a 16F887.

Kerry


Sergey Dryga wrote:
{Quote hidden}

-- Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.289 / Virus Database: 267.11.13 - Release Date: 10/6/05

2010\12\30@214305 by William \Chops\ Westfield

face picon face
>> FOSS definitely helped C a lot, even before it was called that.  
>> First there was the portable C compiler, which lasted through the  
>> late 1980s.  Then there was gcc.

> And lets not forget MAD (Michigan Algorithm Decoder) running on IBM  
> 709 (vacuum tubes) and 7090 (solid state) in the early 1960's. It  
> helped a lot to have Alfred E. Newman's picture on the cover. :)  
> Then in the mid 1970's there was Basic running on a Univac 1108.

I can't tell whether you're making fun of my "ancient history" or if  you're serious.  I claim it was in the 80s that C pulled ahead of  everything else, so to figure out why, you need to look at the things  that happened in the late 70s and early 80s.

I suppose the policies of mainframe and larger computer vendors toward  universities had a lot to do with things.  Waterloo Fortran, Dartmouth  and Stonybrook Basic, Cornell PL/C, Stanford SAIL, Rutgers Pascal,  Penn APL, who knows how many LISP implementations...  But nothing  aimed at microcontrollers; there were CP/M machines, 6502 SBCs, and  small PDP/11s around, but I'm not aware of anyone doing language  development for them (I was sort of mainframe-oriented in those days,  so I could be mistaken.  But I certainly recall that most languages  for micros came from entrepreneurial hackers like Bill Gates.)  I  guess part of the problem was the lack of storage on a lot of those  micros.  Cross-compilers for mainframes weren't very interesting to  the people without a mainframe, and the people that did have the  mainframe were writing other stuff...)

BillW

2010\12\30@224137 by Harold Hallikainen

face
flavicon
face
> Cross-compilers for mainframes weren't very interesting to
> the people without a mainframe, and the people that did have the
> mainframe were writing other stuff...)
>
> BillW

I got started with the MC6800 (actually the MC6802). I wire wrapped a chip
with a bunch of 1kx4 RAMs and a Motorola MIKBUG ROM. I used the 6800 cross
assembler at The Source, an early consumer oriented time share service. I
built a 300bps modem and dialed from San Luis Obispo CA to Ventura CA, the
closest Telenet dial-in point. On weekends I paid $7 per hour for the
phone call and $5 per hour for use of the Source.

Stuff has changed...

Harold


-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2010\12\30@232042 by Harold Hallikainen

face
flavicon
face
As a follow-up, I mentioned The Source in my last post. Here's a little
more info on them:

http://books.google.com/books?id=XtQDAAAAMBAJ&lpg=PA10&ots=ldmkuFY_00&dq=%22the%20source%22%20computer%20time%20share&pg=PA10#v=onepage&q=%22the%20source%22%20computer%20time%20share&f=false

http://tinyurl.com/267vokl

Harold


-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2010\12\31@003111 by Neil Cherry

flavicon
face
On 12/30/2010 09:43 PM, William "Chops" Westfield wrote:
{Quote hidden}

I recall those times and C was just catching on for the micros. I
recall learning C for my Atari 800xl (Deep Blue C). BASIC was the
popular language for micros (Rockwell AIM, Commodore 64, Apple 2,
Timex Sinclair. etc.) It was BASIC and assembly (with Peeks, Pokes,
and USR). When C was introduced it allowed more structured code
than BASIC (lots of gotos and gosubs). When the IBM PC became
available C had been on CP/M (as was BASIC). When the IBM PC
arrived it was BASIC, Assembly, C and PASCAL. I recall PASCAL
being hard for those of use who were used to Assembler. Way
to rigid. Much of the Pascal was some weird IBM P-Code that
ran lousy on the tiny micros. It also didn't let us access what
was on the Micros. It had it's own OS.

Of course I had used OS/9 & OS/K before I had used a PC and wondered
why anyone would tolerate a single user OS instead of a multi-tasking/
multi-user OS. Seemed pretty dumb to me. Oh, we had structured
BASIC (like Pascal), Pascal and C. C always seemed like a super macro
assembly language. It was easy to understand, easy to debug since
the code pretty much read like assembler (just less typing).

-- Linux Home Automation         Neil Cherry       RemoveMEncherryTakeThisOuTspamlinuxha.com
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:            Linux Smart Homes For Dummie

2010\12\31@034535 by Wouter van Ooijen

face picon face
> If one follows all suggestions by Stroustrup, would we not get C++?

Stroustroup's hands were very much tied behind his back by the practical wish to remain compatible with C. If he had designed C++ from scratch (or even allowed more incompatibilities with C) it would have been very different.

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\12\31@035026 by Michael Watterson

face picon face
On 30/12/2010 21:28, William "Chops" Westfield wrote:
> On Dec 29, 2010, at 3:35 PM, Michael Watterson wrote:
>
>>> yet we are (almost) all using C ...  Why? I guess C
>>> must have done something right, but I am not sure what it is.
>> Purely because C was language of Choice for UNIX, BSD, MSDOS,
>> Windows, Linux.
>>
>> Popularity rather than anything.
> Your memory doesn't match my memory.  "popularity" would have meant
> that we'd all be programming in Fortran or Cobol.  Unix wasn't
> generally available.  MSDOS C compilers lagged other languages by
> several years.  Early C compilers were pretty sucky.  Borland's Pascal
> was pretty good pre-dated their C compiler by quite a bit.
>
> What happened to Algol and PL/1 ?  Both languages featuring "modern"
> concepts and with large amounts of vendor support?  Bliss?
>
>
I think you are thinking more of 60s & 70s and Mainframes / Minicomputers. Not the faster growth areas of CP/M, UNIX, BSD, MSDOS and later Windows on MSDOS that did so well it killed OS/2. An irony that the inferior Win3.x / Win95 killed OS/2 between 1992 & 1996 rather than the superior NT (1993 onward, later renamed Windows2000, XP, Vista and Windows 7). Linux kernel (only, not entire OS) released same time  as NT3.1. It's taken Linux 17 years to reach NT4.0 levels of usability and functionality (I've used USB on NT4.0, a marketing decision by MS to not put that in SP5 or SP6 and kill SP7)

I'm thinking of late 1970s to 1980s, Z80, x86, 68K

Fortan and Cobol hardly used and very expensive on CP/M and MSDOS compared to C and Assembler.

I learnt Qubol (Algol derived pre-Pascal teaching language) in 1960s and ForTran in 1970s
I Learnt and used from 1979  to 1992: Assembler, Pascal, Forth,  Occam,  Modula-2 (Z80, 8051, NEC 78HC11, 68K, x86 on MS-DOS, Cromix, and embedded Industrial/Telecom systems)  but the Commercial pressure was to use "C".  So I did C++ from 1987 and C from 1988 I think.

Colleges taught Modula-2 badly. It suffered from people treating it as Pascal and not realising the protential, just like C++ users programmed in C.

Today the same Colleges are teaching Java, C and C++ badly.

2010\12\31@050456 by Michael Watterson

face picon face
On 31/12/2010 08:45, Wouter van Ooijen wrote:
>> If one follows all suggestions by Stroustrup, would we not get C++?
> Stroustroup's hands were very much tied behind his back by the practical
> wish to remain compatible with C. If he had designed C++ from scratch
> (or even allowed more incompatibilities with C) it would have been very
> different.
>
Agreed.
AT&T crippled C++, I've read Stroustroup's original book and various postings over the years. C++ would not have been much compatible at all, but far better and most bugs and security issues from sloppy C programming and C style usage of C++ would not exist

2010\12\31@054923 by Joep Suijs

picon face
What about C#? Got the experience of Delphi and C++ builder (through
the designer iirc), but had not to be compatible.

Joep


2010/12/31 Michael Watterson <spamBeGonemikespamBeGonespamradioway.org>:
{Quote hidden}

>

2010\12\31@061914 by Michael Watterson

face picon face
On 31/12/2010 10:49, Joep Suijs wrote:
> What about C#? Got the experience of Delphi and C++ builder (through
> the designer iirc), but had not to be compatible.
>
> Joep
C# is basically derived from MS J++, the version of Java MS did and got sued for! C# Strings are similar to the Strings in VB which carry a length descriptor in front and thus don't rely purely on null termination.

C# more in common with VB6 and Java. VB.net is practically C# with VB like syntax, so better off to learn C# for  .net programming. VB6 really the last VB and VB5 the first decent version!

2010\12\31@071932 by Dave Tweed

face
flavicon
face
William "Chops" Westfield wrote:
> I suppose the policies of mainframe and larger computer vendors toward  
> universities had a lot to do with things.  Waterloo Fortran, Dartmouth  
> and Stonybrook Basic, Cornell PL/C, Stanford SAIL, Rutgers Pascal,  
> Penn APL, who knows how many LISP implementations...  But nothing  
> aimed at microcontrollers; there were CP/M machines, 6502 SBCs, and  
> small PDP/11s around, but I'm not aware of anyone doing language  
> development for them (I was sort of mainframe-oriented in those days,  
> so I could be mistaken.  But I certainly recall that most languages  
> for micros came from entrepreneurial hackers like Bill Gates.)  I  
> guess part of the problem was the lack of storage on a lot of those  
> micros.  Cross-compilers for mainframes weren't very interesting to  
> the people without a mainframe, and the people that did have the  
> mainframe were writing other stuff...)

But that's precisely the point: C was developed for and on the PDP series
of minicomputers because Kernigan and Ritchie had one didn't have access to
mainframes. Also, it was designed specifically to make low-level programming
(operating systems and libraries) easy, not abstract programming in general..
As a result, it had many attributes that made it ideal for microcomputers as
well when they became available, PLUS a large number of experienced people
who were able and motivated to make the port.

-- Dave Twee

2010\12\31@073156 by Wouter van Ooijen

face picon face
> AT&T crippled C++, I've read Stroustroup's original book and various
> postings over the years. C++ would not have been much compatible at all,
> but far better and most bugs and security issues from sloppy C
> programming and C style usage of C++ would not exist.

I don't think AT&T did anything. Stroustroup decided to be compatible with C. The result is
- C++ is a compromise langue
- it is in widespread use

The alternative (which he rejected, I think correctly) was to make C++
- a much better language
- used by almost no-one.

--
Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\12\31@164713 by William \Chops\ Westfield

face picon face

>> What about C#?

The C#-powered Netduino (32bit ARM with 512K of flash and 128k of ram,  used 384k/48k for C# runtime environment) is looking like it might  give the Arduino (8bit AVR w 32k/2k, 2k/150) a run for its money, for  those developers willing to be restricted to a Windows development  environment.

(I'm not sure just how tongue-in-cheek that sentence should be, given  that the two boards sell for a similar price... ($35 vs $30))

BillW

2010\12\31@185309 by Michael Watterson

face picon face
On 31/12/2010 21:47, William "Chops" Westfield wrote:
>>> What about C#?
> The C#-powered Netduino (32bit ARM with 512K of flash and 128k of ram,
> used 384k/48k for C# runtime environment) is looking like it might
> give the Arduino (8bit AVR w 32k/2k, 2k/150) a run for its money, for
> those developers willing to be restricted to a Windows development
> environment.
>
> (I'm not sure just how tongue-in-cheek that sentence should be, given
> that the two boards sell for a similar price... ($35 vs $30))
>
> BillW
>
Mono on Linux for .net? Dunn


'[PIC] C syntax in assembler'
2011\01\01@090947 by N. T.
picon face
Michael Watterson wrote:
> William "Chops" Westfield wrote:
>>>> What about C#?
>> The C#-powered Netduino (32bit ARM with 512K of flash and 128k of ram,
>> used 384k/48k for C# runtime environment) is looking like it might
>> give the Arduino (8bit AVR w 32k/2k, 2k/150) a run for its money, for
>> those developers willing to be restricted to a Windows development
>> environment.
>>
>> (I'm not sure just how tongue-in-cheek that sentence should be, given
>> that the two boards sell for a similar price... ($35 vs $30))
>>
>> BillW
>>
> Mono on Linux for .net? Dunno
>

He said, "for those developers willing to be restricted to a Windows
development environment". The dev environment is called MS Visual
Studio, if I am not mistaken

2011\01\01@220303 by William \Chops\ Westfield

face picon face

On Jan 1, 2011, at 6:09 AM, N. T. wrote:

>> Mono on Linux for .net? Dunno
>>
>
> He said, "for those developers willing to be restricted to a Windows  
> development environment". The dev environment is called MS Visual  
> Studio, if I am not mistaken.

"mono" is an open source version of C#/.net, and runs on windows/linux/ macos, but I don't know whether it supports the ".net micro framework"  used by netduino.

Whatever happened to P-code (for pascal), anyway?  It seems (?) that  interpreters in general have advanced in the relatively recent past;  were there enough advantages in the p-code runtime environment to  think about doing that again, or have the (older) advances made in  compiler technology made it uninteresting anyway?  (I never noticed  whether P-code added run-time capabilities to a typical CPU, or was  just a crutch so people wouldn't have to write code generators.)

BillW

2011\01\02@025301 by N. T.

picon face
William "Chops" Westfield wrote:
> "mono" is an open source version of C#/.net, and runs on windows/linux/
> macos, but I don't know whether it supports the ".net micro framework"
> used by netduino.
>

It is possible, I believe, as the ".net micro framework" is open source too..

As netduino will be supporting >600MHz  ARMs, I won't be surprised if
they added an open source Op System over the ".net micro framework".
They say some boards support extra DSPs and blocks of code written in
C

2011\01\02@050159 by Michael Watterson

face picon face
On 02/01/2011 03:03, William "Chops" Westfield wrote:
> Whatever happened to P-code (for pascal), anyway?  It seems (?) that
> interpreters in general have advanced in the relatively recent past;
> were there enough advantages in the p-code runtime environment to
> think about doing that again, or have the (older) advances made in
> compiler technology made it uninteresting anyway?  (I never noticed
> whether P-code added run-time capabilities to a typical CPU, or was
> just a crutch so people wouldn't have to write code generators.)
>
> BillW
Doesn't Java, VB6 and  .Net all use a type of "p-code" on a virtual machine.  I believe true ".net code" is not x86 but portable to .net implemented on any architecture being derived from MS Java machine, the J++ project?

So I go and have a look ...

MS P-Code as produced by VB6, may or may not be related http://en.wikipedia.org/wiki/Microsoft_P-Code
<< Microsoft's P-Code, short for packed code, is an intermediate language that provides an alternate binary format to native code for any compiled binary (eg: DLLs, ActiveX controls, or Applications). >>

<< Programs written for the .NET Framework execute in a software (as contrasted to hardware) environment, known as the Common Language Runtime (CLR). The CLR is an application virtual machine so that programmers need not consider the capabilities of the specific CPU that will execute the program. >>
http://en.wikipedia.org/wiki/.NET_Framework

<< James Gosling cites UCSD Pascal as a key influence (along with the Smalltalk virtual machine) on the design of the Java virtual machine.>>
http://en.wikipedia.org/wiki/UCSD_p-System

ARM has Jazelle which is added Java byte code support. That's a bit like P-Code support. There was Western Digital chip set that ran UCSD p-code  as its instruction set in 1980s.
http://en.wikipedia.org/wiki/Jazelle

Also intermediate stage of many languages prior to final pass to native code uses *a* "p-code" language to make porting the language (new back end p-code to assembler) and split optimisation between source optimisation and target cpu optimisations. JALV2 is one.

On 02/01/2011 03:03, William "Chops" Westfield wrote:
<<  Whatever happened to P-code (for pascal), anyway? >>

Seems the concept is alive and well  ^_

2011\01\06@074407 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> Wouter van Ooijen wrote:
>> Why? I guess C must have done something right, but I am not sure what
>> it is.
>
> Market acceptance is based on a number of factors, with technical
> superiority not usually near the top of the list.
>
> In think C got popular for various reasons, some having to do with
> history and luck.  One technical point in its favor was that it was
> relatively easy to write a compiler for.  The syntax changes I would
> have liked wouldn't have made it harder though I think.
>
> In my opinion, another factor is specifically because it is such a
> "bad" language.  Especially in the early 1980s when C was at its
> steepest rise, there was a lot of "I don't need no stink'n type
> checking" attitude and the like.  
Most of arguments that go like this miss the simple fact that
Turbo-Pascal on the MS-DOS PC was very popular, long before C on the PC
became popular. At least as I experienced it, programming on the early
PC was heavily slanted towards BASIC and (Turbo-)Pascal, C having been
almost unknown.

Probably one obstacle Pascal faced was that in order to be useful, the
original language spec had to be extended, and every vendor extended it
in its own way, usually incompatible with other vendors.

I think that much of the weirdness of C can easily be explained with its
history. Let's say somebody ported Olin's PIC assembly environment to a
mainframe and wrote a database application using it -- one could easily
find many things to criticize if one were to forget that it once was a
perfectly useful development environment for embedded systems based on
PICs. C was developed mainly to help port an OS from one system to
another, sort of a portable assembly language that is low level enough
to allow expressing anything you may want to express in assembly in C,
yet abstract enough to be easily implemented in different assembly
languages, but not too abstract as to make compiler writing reasonably
easy. It wasn't designed from scratch (the name!), but rather had
history and pre-existing code base. You just don't write from scratch if
you don't have to, you modify what you already have to suit your needs
-- if the outcome is "good enough" for the purpose and if the
modification is less work than writing from scratch. That's simply
normal engineering.


It's one of those local optimums that, from far away and high above, are
easily spotted as not globally optimal, but at the time and for the
given purpose may very well have been a perfectly suitable local
optimum. The same goes for the shortcomings of Pascal that prevented it
from becoming the language of choice on the PC, even though it was
already almost there -- it was designed as teaching aid, not as
application development language. Also sort of like the use of
non-metric units and hardware in the USA... the switch period in most
countries was probably around a decade (UK a bit longer), but the USA
will probably hit a century or so -- even though eventually it will
happen. While there are many "local optimum" reasons for this, it's
definitely not a global optimum solution. But unless forced by a body
that has the power to force it (like the switch to metric units and
hardware in some countries), it's mostly those local optimums that
determine how things are done. I'm sure you could appreciate the local
optimum situation that led to C, with all the smaller and bigger
compromise decisions that had to be made, if you could just let your
grudge aside for a while :) The rest then is history... Pascal had its
shot, was almost there, but some shortcomings in it prevented it from
really happening.

(I still feel the sadness I felt when I had to abandon Turbo-Pascal
because it just didn't make it into the professional market. It was
years -- probably a decade -- ahead of any C environment on the PC.)

Gerhar

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...