Searching \ for '[EE] Languages, was Bug in Microchip mcc18 std lib' 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=language
Search entire site for: 'Languages, was Bug in Microchip mcc18 std lib'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Languages, was Bug in Microchip mcc18 std lib'
2005\02\16@111022 by Tony Smith

picon face
{Quote hidden}

catcher.
{Quote hidden}

Click Tools / Option.  Untick 'Auto Syntax Check'.  Dodgy lines will still
show up as red, but the annoying message goes away.  Works in VBA (Excel,
Word, Autocad etc too)

C was designed to make compilers easy to write, hence dumb stuff like case
sensitivity. Fancy Basic getting it right. (QuickBasic did the fix
capitalisation trick too).

Not sure if Borland Pascal did.  One thing I liked about Pascal was stating
a variables min/max range when declared.

Something like  Counter As Int 1..100

The statement Counter = 106 causes an error.  Saves putting asserts all over
the place.

While we're at it, anyone want defend the break statement used by C in
switch/case?

Tony

2005\02\16@120900 by Walter Banks

picon face


Tony Smith wrote:

> C was designed to make compilers easy to write, hence dumb stuff like case
> sensitivity. Fancy Basic getting it right.

C is significantly harder to write a compiler for than many other languages
including all of the Wirth languages and Basic. Case sensitivity is designers
choice and the stuff for endless net threads.

> Not sure if Borland Pascal did.  One thing I liked about Pascal was stating
> a variables min/max range when declared.
>
> Something like  Counter As Int 1..100
>
> The statement Counter = 106 causes an error.  Saves putting asserts all over
> the place.

Pascal's data typing and data checking is a real asset. C99 finally got
part of data types right with size specific declarations essential for portable
embedded systems code. Range and user defined data types are not
available in C and wouldn't detract from code efficiency if they were.

> While we're at it, anyone want defend the break statement used by C in
> switch/case?

I see a gauntlet. A C switch statement is an computed goto similar to other
languages but organized to to allow multiple entry points into straight line
application source code. The break is syntax candy that is a label_less
goto to the end of the switch block from any point within the block. It
makes application control scope management easy in complex control
structures and eliminates the need for developers to add labels to their
code at the end of switch structures. It might be pointed out the developer
is still free to use their own labels and goto's instead of breaks.

w..



2005\02\16@130443 by Wouter van Ooijen

face picon face
> C is significantly harder to write a compiler for than many
> other languages
> including all of the Wirth languages and Basic. Case
> sensitivity is designers
> choice and the stuff for endless net threads.

The confusion is probably that the C *semantics* (the meanting of the
program) are relatively easy to translate coompared to many other
languages (hence: C is a low-level HLL). But the C *syntax* (the format)
is difficult to parse and interpret.

Wouter van Ooijen

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



2005\02\16@131816 by D. Jay Newman

flavicon
face
> Tony Smith wrote:
>
> > C was designed to make compilers easy to write, hence dumb stuff like case
> > sensitivity. Fancy Basic getting it right.
>
> C is significantly harder to write a compiler for than many other languages
> including all of the Wirth languages and Basic. Case sensitivity is designers
> choice and the stuff for endless net threads.

This strongly depends on the year you are talking about.

When C was first created, case sensitivity made the C compiler *much*
easier to write. Likewise the case sensitivity in Unix.

Even in English case insensitivity opens up a large can of worms. Once you
go to other languages there are different rules for casing.

Yes, I prefer case insensivity. It makes things easier for the programmers
(people) to read. However, I take what I can get.
--
D. Jay Newman           ! Polititions and civilations come and
jayspamspam_OUTsprucegrove.com     ! go but the engineers and machinists
http://enerd.ws/robots/ ! make progress

2005\02\16@132220 by William Chops Westfield

face picon face
On Feb 16, 2005, at 9:04 AM, Walter Banks wrote:

> Pascal's data typing and data checking is a real asset.

If you can afford it, I guess.  I think C wins because of the
low requirements it places on the runtime environment.  No
runtime checking, no runtime libraries, nothing.  Fits good
in a 1k microcontroller, or a 64k embedded system.
The "mainframe" (windows, linux, etc) environment is quite
different, and it's interesting to watch new languages become
near-necessities as the amount of boilerplate you need to implement
even a simple program.

In other words, C succeeds on micros because it has minimal assumptions
about the runtime environment, and other languages succeed on other
systems because their assumptions about the runtime environment (and
support thereof) are well matched to the actual requirements.

(and that goes back to fortran's assumptions about cards and line
printers vs basic's assumptions about ASR33-like devices.)

BillW

2005\02\16@132340 by William Chops Westfield

face picon face

On Feb 16, 2005, at 10:04 AM, Wouter van Ooijen wrote:

> the C *syntax* is difficult to parse and interpret.
>
The C syntax pre-dates most of the "computer science" of
parsing and etc, right?

BillW

2005\02\16@134612 by olin_piclist

face picon face
Walter Banks wrote:
> I see a gauntlet. A C switch statement is an computed goto similar to
> other languages but organized to to allow multiple entry points into
> straight line application source code. The break is syntax candy that
> is a label_less
> goto to the end of the switch block from any point within the block. It
> makes application control scope management easy in complex control
> structures and eliminates the need for developers to add labels to their
> code at the end of switch structures. It might be pointed out the
> developer
> is still free to use their own labels and goto's instead of breaks.

I suspect the original point was not BREAK versus manual labels, but
explicit BREAK versus implied break at the end of each case is in Pascal for
example.  In Pascal, there is an automatic jump to the end of the CASE
statement after the statement for each individual case.  If you want a case
to be more than one statement long, you enclose it in BEGIN/END.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\16@140103 by Peter Johansson

flavicon
face
William Chops Westfield writes:

> If you can afford it, I guess.  I think C wins because of the
> low requirements it places on the runtime environment.  No
> runtime checking, no runtime libraries, nothing.  Fits good
> in a 1k microcontroller, or a 64k embedded system.
> The "mainframe" (windows, linux, etc) environment is quite
> different, and it's interesting to watch new languages become
> near-necessities as the amount of boilerplate you need to implement
> even a simple program.
>
> In other words, C succeeds on micros because it has minimal assumptions
> about the runtime environment, and other languages succeed on other
> systems because their assumptions about the runtime environment (and
> support thereof) are well matched to the actual requirements.

It is also worth noting that the C language has very close ties to the
VAX architecture it was first implemented on, very much in the same
way that Atypical is closely tied to the PIC instruction set.  I
visited the page when the link first hit the list and was most
impressed.  I hope the author has the time to bring the project
together and release it to the community.

-p.

2005\02\16@140902 by olin_piclist

face picon face
William Chops Westfield wrote:
>> Pascal's data typing and data checking is a real asset.
>
> If you can afford it, I guess.  I think C wins because of the
> low requirements it places on the runtime environment.

The Pascal type checking is done at compile time, so puts no burden onto the
final code.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\16@141204 by olin_piclist

face picon face
Peter Johansson wrote:
> It is also worth noting that the C language has very close ties to the
> VAX architecture it was first implemented on,

C predates the VAX.  If I remember right, it was first implemented on a
PDP-11.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\16@142941 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Peter Johansson" <@spam@peterKILLspamspamelemental.org>
Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?


> It is also worth noting that the C language has very close ties to the
> VAX architecture it was first implemented on, very much in the same

ummmm ... C preceeded the VAX by quite a long time.  In fact, the VAX
architecture was very much designed with Pascal in mind.  Indeed, there is a
lot about the VAX that is remarkably un C-like.  Ritchie dates C to 1969-73,
and on his web site, has compiler sources from '72.  The VAX didn't appear
until the early 80's.

--McD


2005\02\16@143542 by Wouter van Ooijen

face picon face
> It is also worth noting that the C language has very close ties to the
> VAX architecture it was first implemented on

Sorry, nonsense. C was first implemented *long* before the VAX-11
architecture. It has some resemblance to the PDP-11 architecture it was
first developed on, but 'close ties' is much too strong. Read
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Wouter van Ooijen

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



2005\02\16@143549 by Wouter van Ooijen

face picon face
> > the C *syntax* is difficult to parse and interpret.
> >
> The C syntax pre-dates most of the "computer science" of
> parsing and etc, right?

Even more: it predates most of what we now know about what is readable
for humans.

Wouter van Ooijen

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


2005\02\16@144122 by Alex Harford

face picon face
On Wed, 16 Feb 2005 14:29:36 -0500, John J. McDonough
<KILLspammcdKILLspamspamis-sixsigma.com> wrote:
> ----- Original Message -----
> From: "Peter Johansson" <RemoveMEpeterTakeThisOuTspamelemental.org>
> Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?
>
> > It is also worth noting that the C language has very close ties to the
> > VAX architecture it was first implemented on, very much in the same
>
> ummmm ... C preceeded the VAX by quite a long time.

I think the original poster probably meant PDP-11 rather than VAX.

Alex

2005\02\16@144448 by D. Jay Newman

flavicon
face
> On Feb 16, 2005, at 10:04 AM, Wouter van Ooijen wrote:
>
> > the C *syntax* is difficult to parse and interpret.
> >
> The C syntax pre-dates most of the "computer science" of
> parsing and etc, right?

Actually C syntax is extremely easy to parse. It was originally designed
to be an almost one-on-one C-statement to assembler-statement translater
for a 16-bit computer.

If you think of the early C syntax without the extensions of the last
decades, this makes sense.
--
D. Jay Newman           ! Polititions and civilations come and
spamBeGonejayspamBeGonespamsprucegrove.com     ! go but the engineers and machinists
http://enerd.ws/robots/ ! make progress

2005\02\16@152229 by Byron A Jeff

face picon face
On Wed, Feb 16, 2005 at 01:45:44PM -0500, Olin Lathrop wrote:
> Walter Banks wrote:
> >I see a gauntlet. A C switch statement is an computed goto similar to
> >other languages but organized to to allow multiple entry points into
> >straight line application source code. The break is syntax candy that
> >is a label_less
> >goto to the end of the switch block from any point within the block. It
> >makes application control scope management easy in complex control
> >structures and eliminates the need for developers to add labels to their
> >code at the end of switch structures. It might be pointed out the
> >developer
> >is still free to use their own labels and goto's instead of breaks.
>
> I suspect the original point was not BREAK versus manual labels, but
> explicit BREAK versus implied break at the end of each case is in Pascal for
> example.  In Pascal, there is an automatic jump to the end of the CASE
> statement after the statement for each individual case.  If you want a case
> to be more than one statement long, you enclose it in BEGIN/END.

I have to admit that it was one of C's major blunders. By implementing break
they made the counterintuitive behavior (fallthrough) the default.

The fix was simple too: the default should have been a break at the end of
each case. Then the 'continue' statement could be used to invoke an explicit
fallthrough.

But it's water under the bridge.

BAJ

2005\02\16@152510 by Walter Banks

picon face
Good point. This is true. C's roots are in structured assemblers. The alternatives
of the day for low level languages were some very interesting macro processors
like Stage2, TRAC and M4.

Language theory was quite young. C has evolved and there is a significant amount
of work to write a clean parser for it.

w..

Wouter van Ooijen wrote:

> > C is significantly harder to write a compiler for than many
> > other languages
>
> The confusion is probably that the C *semantics* (the meanting of the
> program) are relatively easy to translate coompared to many other
> languages (hence: C is a low-level HLL). But the C *syntax* (the format)
> is difficult to parse and interpret.
>


2005\02\16@152911 by Walter Banks

picon face


Peter Johansson wrote:

> > In other words, C succeeds on micros because it has minimal assumptions
> > about the runtime environment, and other languages succeed on other
> > systems because their assumptions about the runtime environment (and
> > support thereof) are well matched to the actual requirements.
>
> It is also worth noting that the C language has very close ties to the
> VAX architecture it was first implemented on

C is actually earlier than VAX, the first versions were in Bell Labs running
on the PDP11 before it was renamed PDP 11/20. Some of the language
work predates the PDP 11.

w..




2005\02\16@154141 by D. Jay Newman
flavicon
face
> > It is also worth noting that the C language has very close ties to the
> > VAX architecture it was first implemented on
>
> Sorry, nonsense. C was first implemented *long* before the VAX-11
> architecture. It has some resemblance to the PDP-11 architecture it was
> first developed on, but 'close ties' is much too strong. Read
> http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Some people sometimes confuse the VAX with the PDP-11, because the VAX was
an upgrade of the PDP-11 architecture. Though, to be honest, I still think
that the PDP-11 has the cleanest assembly language of any machine I've
used.
--
D. Jay Newman           ! Polititions and civilations come and
TakeThisOuTjayEraseMEspamspam_OUTsprucegrove.com     ! go but the engineers and machinists
http://enerd.ws/robots/ ! make progress

2005\02\16@155218 by Walter Banks

picon face
I partly agree. The Pascal case is a lot like a long if then else if ... string
where there are small amounts of code for each index. C is more like the
Dartmouth basic concept of computed branches. Pascal likes single entry
points. C at least early C wanted to make sure and program structure
that was available in assembly code would be available in C. As a
structured assembler it could do that on processors of the day. Some of the
ISO C Standards for Embedded Systems has been to bring C back to its
roots to eliminate the need for assembler for missing language reasons.

The point about labels is well taken although we are often taken to task
about why C has break and continue and what are their usage rules.

w..


Olin Lathrop wrote:

{Quote hidden}

2005\02\16@160158 by Harold Hallikainen

face picon face

> Some people sometimes confuse the VAX with the PDP-11, because the VAX was
> an upgrade of the PDP-11 architecture. Though, to be honest, I still think
> that the PDP-11 has the cleanest assembly language of any machine I've
> used.


I agree! It was amazing how things worked out when you started mixing
various modes and registers to get immediate addressing, indirect
addressing, etc. As I recall, the instruction word was always something
like this:

Operation - Source Register - Source Mode - Destination Register -
Destination Mode

How you mixed those created tha magic.

Harold


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

2005\02\16@163046 by Wouter van Ooijen

face picon face
> I have to admit that it was one of C's major blunders. By
> implementing break
> they made the counterintuitive behavior (fallthrough) the default.

But it (plus a few other C 'features') makes possible a programming
construct that is at the same beatiful and ugly: the interleaved
for/switch, which unrolls a for loop while (with the same code) handling
the left-over iterations. I forgot what it's called though.

Wouter van Ooijen

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


2005\02\16@163617 by David P Harris

picon face
D. Jay Newman wrote:

>... Though, to be honest, I still think
>that the PDP-11 has the cleanest assembly language of any machine I've
>used.
>  
>
Hear, hear!

David

2005\02\16@165622 by Robert Rolf

picon face
Harold Hallikainen wrote:

>>Some people sometimes confuse the VAX with the PDP-11, because the VAX was
>>an upgrade of the PDP-11 architecture. Though, to be honest, I still think
>>that the PDP-11 has the cleanest assembly language of any machine I've
>>used.
>
>
>
> I agree! It was amazing how things worked out when you started mixing
> various modes and registers to get immediate addressing, indirect
> addressing, etc. As I recall, the instruction word was always something
> like this:
>
> Operation - Source Register - Source Mode - Destination Register -
> Destination Mode

Close.
Byte/Op/SReg/Smode/DReg/Dmode
More than you ever wanted to know about PDP 11 architecture.

research.microsoft.com/users/GBell/CGB%20Files/New%20Architecture%20PDP11%20SJCC%201970%20c.pdf
Page 672.


> How you mixed those created tha magic.

My favourite was the 'fill memory' instruction.

Mov -(R7),-(R7) ;move predecrement indirect program counter to ...

Placed at top of memory it copied itself down to the bottom
and then caused a halt with bus fault (no memory).

Robert

2005\02\16@172938 by Matthew Miller

flavicon
face
On Wed, Feb 16, 2005 at 10:30:46PM +0100, Wouter van Ooijen wrote:
> But it (plus a few other C 'features') makes possible a programming
> construct that is at the same beatiful and ugly: the interleaved
> for/switch, which unrolls a for loop while (with the same code) handling
> the left-over iterations. I forgot what it's called though.

Wouter, I think you may be talking about "Duff's device". Here is a
link: http://www.lysator.liu.se/c/duffs-device.html

Even if I'm mistaken, Duff's device is very interesting.

Matthew.

--
(\(\
(^.^)
(")")

2005\02\16@223715 by Peter Johansson

flavicon
face
Byron A Jeff writes:

> I have to admit that it was one of C's major blunders. By implementing break
> they made the counterintuitive behavior (fallthrough) the default.

Going back a quick step, I was the one who compared C to the VAX arch,
and what I meant (as several people picked up on) was that I really
meant PDP instruction set.

That said, you need to think about how the switch statement related to
the lower assembly instruction set:  a switch statement is compiled as
a series of compare/branch-equal statements.  All of the code within
the switch statement is then simply compiled as a block.

It's only counter-intuitive if you learn C *after* working with other
high-level languages.  But the reality is that C isn't a high-level
language.  IMO, C++ was a much larger blunder, attempting to take a
mid-level language and turn it into a higher-level OO language where
it failed on both counts.

-p.

2005\02\16@230226 by Bob Ammerman

picon face
Here is an odd bit of C code....

Do you think it is legit ?


   switch  (n)
       default::
           if (isprime(n))
               case 2: case 3: case 5: case 7: p = 1;
           else
               case 4: case 6: case 8 case 9: : p=0;

If it is, what on earth does it do?  (and why!)

:-)

Bob Ammerman
RAm System

2005\02\16@234058 by William Chops Westfield

face picon face

On Feb 16, 2005, at 1:30 PM, Wouter van Ooijen wrote:

> But it (plus a few other C 'features') makes possible a programming
> construct that is at the same beatiful and ugly: the interleaved
> for/switch, which unrolls a for loop while (with the same code)
> handling
> the left-over iterations. I forgot what it's called though.
>
I think you're talking about "Duff's device"

 send(to, from, count)
  register short *to, *from;
  register count;
  {
   register n=(count+7)/8;
   switch(count%8){
    case 0:do{*to = *from++;
    case 7:*to = *from++;
    case 6:*to = *from++;
    case 5:*to = *from++;
    case 4:*to = *from++;
    case 3:*to = *from++;
    case 2:*to = *from++;
    case 1:*to = *from++;
   }while(--n>0);
  }
 }

2005\02\16@235233 by William Chops Westfield

face picon face

On Feb 16, 2005, at 7:37 PM, Peter Johansson wrote:

> I really meant PDP instruction set.

PDP-11.  Don't forget the "11" part.
The PDP-8 was much different, as were the PDP-6 and PDP-10
(which were rather alike.)

Ah, the heyday of computing, when a company could come out with
a new computer that was NOT AT ALL LIKE their previous computer,
except supporting some of the same languages and utilities
(applications?  That's what the customers write.)  Several
different PDP6, 8, 10, and 11 operating systems all had PIP,
for instance.)

BillW

2005\02\17@001305 by Byron A Jeff

face picon face
On Wed, Feb 16, 2005 at 10:30:46PM +0100, Wouter van Ooijen wrote:
> > I have to admit that it was one of C's major blunders. By
> > implementing break
> > they made the counterintuitive behavior (fallthrough) the default.
>
> But it (plus a few other C 'features') makes possible a programming
> construct that is at the same beatiful and ugly: the interleaved
> for/switch, which unrolls a for loop while (with the same code) handling
> the left-over iterations. I forgot what it's called though.

Duff's device.

http://catb.org/~esr/jargon/html/D/Duffs-device.html

Like I said in my post, allowing the continue keyword to failitate fallthrough
would still allow for it.

Having the break by default would save a lot of upcoming C students some grief.

BAJ

2005\02\17@022650 by Wouter van Ooijen

face picon face
> Here is an odd bit of C code....
> Do you think it is legit ?

yes, why not?

>     switch  (n)
>         default::
>             if (isprime(n))
>                 case 2: case 3: case 5: case 7: p = 1;
>             else
>                 case 4: case 6: case 8 case 9: : p=0;
>
> If it is, what on earth does it do?

compute whether n is prime

> (and why!)

it speeds up the prime-check for < 10, and defers the check for >= 10 to
isprime(), without using extra 'return' statements. This makes sense
only if the objective is to minimise the number of return statements.


Wouter van Ooijen

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


2005\02\17@022650 by Wouter van Ooijen

face picon face
> Wouter, I think you may be talking about "Duff's device". Here is a
> link: http://www.lysator.liu.se/c/duffs-device.html

Yep, that's it. It depends on both the switch-fallthrough and the even
more bizarre possibility of scattering the switch labels outside *and*
inside the do loop. Next time, think twice before calling C a 'block
structured' language!

Wouter van Ooijen

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


2005\02\17@022650 by Wouter van Ooijen

face picon face
> IMO, C++ was a much larger blunder, attempting to take a
> mid-level language and turn it into a higher-level OO language where
> it failed on both counts.

That's like saying that Newton was a lousy athlete, all US spacecraft
fail miserably as commuter vehicles, and the <fill in your favourite
athlete> is a lousy C programmer.

C++ was designed to be (almost) upwards compatible to C, both as
language and in the code produced. Within that constraint it is a
marvelous design. Without that constraint a much much better language
could have been designed, but you probably wouldn't even know it
existed. Do you know all about Eiffel, Miranda, Haskell and CLU? Did you
ever use one of these languages? Do you know a free compiler (or even a
commercial) for your faviourite computer?

Wouter van Ooijen

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


2005\02\17@043813 by Alan B. Pearce

face picon face
>> It is also worth noting that the C language has very close ties to the
>> VAX architecture it was first implemented on,
>
>C predates the VAX.  If I remember right, it was first implemented on a
>PDP-11.

I thought it went even earlier than that, I seem to recall that the earliest
versions were started on PDP-8 or PDP-10, but didn't really get going until
the PDP-11. I haven't followed the link that Wouter gave, just going from
vague memories.

2005\02\17@044045 by Alan B. Pearce

face picon face
>Some people sometimes confuse the VAX with the PDP-11, because the VAX was
>an upgrade of the PDP-11 architecture. Though, to be honest, I still think
>that the PDP-11 has the cleanest assembly language of any machine I've
>used.

I seem to recall that the earliest VAX machines had a PDP-11 inside them to
load the microcode to boot the VAX up.

2005\02\17@050301 by Alan B. Pearce

face picon face
>> I have to admit that it was one of C's major blunders. By
>> implementing break they made the counterintuitive behavior
>> (fallthrough) the default.

>It's only counter-intuitive if you learn C *after* working
>with other high-level languages.  But the reality is that
>C isn't a high-level language.

I seem to recall people calling it a "high level assembler", and when looked
at like that, then it makes a lot more sense.

2005\02\17@073613 by Byron A Jeff

face picon face
On Thu, Feb 17, 2005 at 10:02:58AM -0000, Alan B. Pearce wrote:
> >> I have to admit that it was one of C's major blunders. By
> >> implementing break they made the counterintuitive behavior
> >> (fallthrough) the default.
>
> >It's only counter-intuitive if you learn C *after* working
> >with other high-level languages.  But the reality is that
> >C isn't a high-level language.
>
> I seem to recall people calling it a "high level assembler", and when looked
> at like that, then it makes a lot more sense.

I argue that it's counter-intuitive because a switch is a structured
form of an if statement. And if statements do not behave in that fashion.

The whole point of not doing assembler is to give the programmer a
meaningful abstraction to work with. The switch statement by
its very nature partitions a value into a set of decision spaces
that the vast majority of the time are mutually exclusive.

So I contend to make the rarely used fallthrough the default behavior
wasn't the right move.

Now there's a second issue at work syntatically. Removing the
default fallthrough would make multiple cases sharing the same code
more problematic. So something like:

switch (letter) {
  case 'A':
  case 'a':
  case 'E':
  case 'e':
 // You get the idea
  case 'u': printf("%c is a vowel\n",letter);
            break;
  default:
            printf("%c is a NOT vowel\n",letter);
            break; // I know it unnecessary. Just habit.
}

Would convert to:

switch (letter) {
  case 'A': continue;
  case 'a': continue;
  case 'E': continue;
  case 'e': continue;
 // You get the idea
  case 'u': printf("%c is a vowel\n",letter);
  default:
            printf("%c is a NOT vowel\n",letter);
}

Which is clearly more cumbersome. Of course I would have preferred having
both lists and ranges for cases. So ideally something like:

switch (letter) {
  case 'A', 'a', 'E', 'e', 'u': printf("%c is a vowel\n",letter);
  default:
            printf("%c is a NOT vowel\n",letter);
}

Would have been the ticket. I personally wouldn't have had a problem
repuposing the comma operator to a different function between the case and
the colon because C doesn't allow for computable expressions in that area
IIRC. Actually I was wrong on that. It can be an expression as long as it's a
compile time evaluation to a constant. However the comma in that area is a
syntax error.

I'm not too interested in the geneology of why the statement came into its
current configuration. I'm just pointing out that syntatically and
semantically there were bettern, more meaningful representations.

BAJ

2005\02\17@074909 by olin_piclist

face picon face
Peter Johansson wrote:
> a switch statement is compiled as
> a series of compare/branch-equal statements.

Not necessarily.  Jump tables are usually a better choice when there are
many cases and the case space is not sparse.  Most compilers are smart
enough to figure out which one is more efficient given the particular
conditions.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\17@075059 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Wouter van Ooijen" <RemoveMEwouterspamTakeThisOuTvoti.nl>
Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?


> C++ was designed to be (almost) upwards compatible to C, both as
> language and in the code produced. Within that constraint it is a
> marvelous design. Without that constraint a much much better language
> could have been designed, but you probably wouldn't even know it
> existed. Do you know all about Eiffel, Miranda, Haskell and CLU? Did you
> ever use one of these languages? Do you know a free compiler (or even a
> commercial) for your faviourite computer?

Absolutely.  And lest we forget, before C++ became popular, object-oriented
programming was sure way to guarantee that a project would fail.  When all
we had avaiable was a bunch of weird languages nobody knew, any OO project
was going to be populated by primmadonnas whose only purpose in life was to
prove that <name your weird language> was the best programming language
ever, and the project really didn't matter.

C++ made OO programming mainstream, and (finally) enabled a critical mass of
OO programmers so that the techniques to make it actually useful could be
developed.

Today there are about a million OO languages.  The only ones that get used
to any extent are C++ and VB, and the only one that gets used for OO
development is C++.  Kinda wonder why that is.

--McD


2005\02\17@075641 by olin_piclist

face picon face
Bob Ammerman wrote:
>    switch  (n)
>        default::
>            if (isprime(n))
>                case 2: case 3: case 5: case 7: p = 1;
>            else
>                case 4: case 6: case 8 case 9: : p=0;
>
> If it is, what on earth does it do?  (and why!)

I don't know enough about C to know whether its legal, and am too lazy to
run it thru a compiler to see.  What is the double colon after DEFAULT?
Shouldn't there be one colon after "8" and only one after "9"?

In any case, it looks like this sets P to 1 if N is prime, and 0 if it's
not.  Values from 2-9 are handled outright, and values outside that range
are evaluated by the ISPRIME function.  At least that's what the intent
appears to be.

While this may be cutesy intellectual exercise, anyone who puts this in
production code should be demoted to assistant mailroom clerk straight away.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\17@075953 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Alan B. Pearce" <A.B.PearceEraseMEspam.....rl.ac.uk>
Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?


> I thought it went even earlier than that, I seem to recall that the
earliest
> versions were started on PDP-8 or PDP-10, but didn't really get going
until
> the PDP-11. I haven't followed the link that Wouter gave, just going from
> vague memories.

Well, Ritchie and company had 'B' on some monster processor at Bell (some
kind of GE mainframe I think).  Seems to me that when they were going to
loose that system, part of the point of C was to work around limitations in
this PDP thingie that they were going to be stuck with.

I keep reading about this history because it is fascinating, but at my
advanced age I have too many other things cluttering up the brain cells so
the details disappear quickly <g>

--McD


2005\02\17@081453 by John J. McDonough

flavicon
face
----- Original Message -----
From: "William Chops Westfield" <EraseMEwestfwspammac.com>
Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?


> (applications?  That's what the customers write.)  Several
> different PDP6, 8, 10, and 11 operating systems all had PIP,
> for instance.)

Ahh PIP ... how did we ever loose that gem.  On today's bloated operating
systems we need half a dozen or a dozen commands to replace the simple and
elegant PIP.  And the VAX had PIP, too, although most folks learned the
DOS-like alternatives instead.  CP/M had it, although I think CP/M had some
syntax differences.

For you young'uns, PIP stands for peripheral interchange program, and it was
copy, cat, move, ls all rolled into one.

ls - PIP /DI
cp filea fileb - PIP fileb=filea
mv filea fileb - PIP fileb=filea /RE
cat filea - PIP TI:=filea
rm filea - PIP filea /DE

Simple, elegant, consistent.  What a wonderful program.

--McD


2005\02\17@082540 by olin_piclist

face picon face
Byron A Jeff wrote:
> So ideally something like:
>
> switch (letter) {
>   case 'A', 'a', 'E', 'e', 'u': printf("%c is a vowel\n",letter);
>   default:
>             printf("%c is a NOT vowel\n",letter);
> }

That is exactly how the Pascal CASE statement works:

case letter of
'A', 'a', 'E', 'e', 'u': writeln (letter, ' is a vowel');
otherwise
 writeln (letter, ' is a NOT vowel');
 end;

(Within the limitation that I, i, O, o, and U aren't vowels.)

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\17@083038 by olin_piclist

face picon face
John J. McDonough wrote:
> ls - PIP /DI
> cp filea fileb - PIP fileb=filea
> mv filea fileb - PIP fileb=filea /RE
> cat filea - PIP TI:=filea
> rm filea - PIP filea /DE
>
> Simple, elegant, consistent.

Hmm.  Your PIP examples seem rather more clunky and verbose than the
alternative on the left.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\17@083101 by Hulatt, Jon

picon face

>
> Today there are about a million OO languages.  The only ones
> that get used
> to any extent are C++ and VB, and the only one that gets used for OO
> development is C++.  Kinda wonder why that is.
>

Don't forget .NET's new one- C# , and of course Java. Some cynics might
argue that C# is Microsoft Java. But not me, no. Anyway, both have a
massive enterprise userbase

2005\02\17@083453 by Alan B. Pearce

face picon face
>> If it is, what on earth does it do?  (and why!)
>
>While this may be cutesy intellectual exercise, anyone who puts this in
>production code should be demoted to assistant mailroom clerk straight
away.

I would agree with your assessment, but the other part that I cannot figure,
is why have a switch statement? It does nothing except fall straight through
to the default case.

2005\02\17@084140 by Wouter van Ooijen

face picon face
> While this may be cutesy intellectual exercise, anyone who
> puts this in
> production code should be demoted to assistant mailroom clerk
> straight away.

In this particular case (and without evidence to the contrary) I agree.
But note that the original Duff's device increased the speed of some
program from unacceptable to good. Anyone who comes up with something
like this to save the day for his company deserves prise.

Wouter van Ooijen

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


2005\02\17@090037 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Hulatt, Jon" <RemoveMEjon.hulattEraseMEspamEraseMEmonster.com>
Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?


> Don't forget .NET's new one- C# , and of course Java. Some cynics might
> argue that C# is Microsoft Java. But not me, no. Anyway, both have a
> massive enterprise userbase

I was going to mention C#, but I don't think it has the penetration of even
Java just yet.  There's a million of them out there.  The interesting thing
is that the hype and the reality are pretty far apart.  Heck, if you believe
the rags, the only language anyone ever uses is Java, maybe with a little
sprinkling of Perl.

But as VS2005 makes its way out, it is hard to see how it can be avoided.
As best I can tell, enterprise folks are almost totally VB.  Sure there is
the occasional outlier, but for the most part I think enterprises see they
can take any monkey off the street and turn him into a VB programmer, and
that seems to be the driver.

But from what I've seen so far, VS2005, especially with C#, has a pretty
compelling story to tell.  If M$ can get that story out, and I see no reason
to suspect they can't, then C# is going to be a hard train to stop.  Now, I
might just be saying that because I don't like VB.  They have made some
pretty amazing improvements to VB development, too.

--McD


2005\02\17@090726 by Bob Ammerman

picon face
Olin,

You are completely right about the misplaced colons. See you understand C
better than you let on :)

And, you are also right about the mailroom reassignment.

Bob Ammerman
RAm Systems

{Original Message removed}

2005\02\17@091051 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: RemoveMEpiclist-bouncesspam_OUTspamKILLspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspamspammit.edu]
>Sent: 17 February 2005 13:42
>To: 'Microcontroller discussion list - Public.'
>Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?
>
>
>> While this may be cutesy intellectual exercise, anyone who
>> puts this in
>> production code should be demoted to assistant mailroom clerk
>> straight away.
>
>In this particular case (and without evidence to the contrary)
>I agree. But note that the original Duff's device increased
>the speed of some program from unacceptable to good. Anyone
>who comes up with something like this to save the day for his
>company deserves prise.
>
>Wouter van Ooijen

Exactly.  It's all very well saying that use of unusual/non-obvious
programming constructs is always bad, but if it's the only way to
acheive a desired goal and is properly documented (unlike the example
given) then I don't see a problem.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\02\17@093851 by Rich Mulvey

flavicon
face
John J. McDonough wrote:

{Quote hidden}

  A lot of it depends on what industry you're in.  I'm in
publishing/printing, and deal with the IT departments of a number of
publishers so that we can integrate systems, and in the 200+ cases I've
dealt with personally, there were exactly 2 that used Microsoft
enterprise products for either the back end systems or the front-end
interfaces.  The vast majority of the rest were Java on the back end and
web clients on the front, with a couple of ancient mainframe systems to
round it out.  Most of the Java/web systems were conversions from MS
products, as well.  ;-)  I'm fairly agnostic about MS development in
general, but honestly, after being married to a Microsoft MVP developer
and watching the extraordinary contortions she had to go through just to
get correct documentation, not to mention dealing with the
ever-present-but-rarely-fixed bugs, I'll stick with Java on
Unix/Linux/etc any day.  ;-)

- Rich

2005\02\17@094826 by Bob Ammerman

picon face
> I would agree with your assessment, but the other part that I cannot
> figure,
> is why have a switch statement? It does nothing except fall straight
> through
> to the default case.

Actually, just like any other switch statement, it does do an jump to the
numbered cases.

Syntactically, a switch statement is defined as:

   switch ( <expression> ) <statement-with-case-labels-in-it>

Under normal circumstances <statement-with-case-labels-in-it> is a compound
statement (i.e.):

{
       <statement>; ....
}

But it works just as well if <statement-with-case-labels-in-it> is replaced
by something like a <if-statement>:

default:
   if (lala)
       case x: case y: do_something();
   else
       case z: do_something_else();

or a <while-statement>

or even a null statement!:

switch (<expression>) ;

which of course is exactly the same as

<expression>;

In all these cases the compiler is supposed to generate code to go to the
case label that matches the <expression>, if there is one, or to the
default: label if there is no match, or to the end of the
<statement-with-case-labels-in-it> if there is no match and there is no
default: label.

Funny stuff indeed.

Bob Ammerman
RAm Systems




2005\02\17@100002 by Wouter van Ooijen

face picon face
> I would agree with your assessment, but the other part that I
> cannot figure,
> is why have a switch statement? It does nothing except fall
> straight through
> to the default case.

It doesn't for the numbers 0..9.

Wouter van Ooijen

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


2005\02\17@100633 by Howard Winter

face
flavicon
picon face
Alan,

On Thu, 17 Feb 2005 10:02:58 -0000, Alan B. Pearce wrote:

> >It's only counter-intuitive if you learn C *after* working
> >with other high-level languages.  But the reality is that
> >C isn't a high-level language.
>
> I seem to recall people calling it a "high level assembler", and when looked
> at like that, then it makes a lot more sense.

When I first encountered it, I called it "An assembler for a machine that doesn't exist" and although I was
being a bit unkind, the parts that aren't like that seem to be horribly confusing to anyone trying to learn
it.  In my opinion (and the reason I didn't go further and learn it properly) it didn't get any closer to
solving the problem than assemblers did, so it wasn't a high-level language, but it didn't let you control the
actual hardware (registers and so on) in the way an assembler did.  So what was the point?  It seems to me to
be more difficult to learn, understand and read than both assemblers and high-level languages.  OK, so perhaps
an experienced expert can make it sing and dance, but a trainee programmer having to follow up and change the
tune would be swamped, and that makes for bad commercial sense in a programming office when developing, for
example, an invoicing and stock-control program.  It may be good for writing operating systems (I've been
told) but how many of the millions of programmers out there do that?

(Shields up, Mr.Sulu! :-)

Cheers,



Howard Winter
St.Albans, England


2005\02\17@101035 by Hulatt, Jon

picon face

> As best I can tell, enterprise folks are almost totally VB.  
> Sure there is
> the occasional outlier, but for the most part I think
> enterprises see they
> can take any monkey off the street and turn him into a VB
> programmer, and
> that seems to be the driver.
>
> But from what I've seen so far, VS2005, especially with C#,
> has a pretty
> compelling story to tell.  If M$ can get that story out, and
> I see no reason
> to suspect they can't, then C# is going to be a hard train to
> stop.  Now, I
> might just be saying that because I don't like VB.  They have
> made some
> pretty amazing improvements to VB development, too.


That train has already left the station here. I work (day job, pic's are
my hobby) for Monster.com. We're an all-microsoft platform, and most of
our codebase is VB/COM, with a light dusting of C++ for some things.

But everything is being written in C# now. A lot of the ancillary parts
of the site are C# already, and by the end of 2005 there should be
almost no VB stuff left.

Jon

2005\02\17@102949 by olin_piclist

face picon face
Alan B. Pearce wrote:
> I would agree with your assessment, but the other part that I cannot
> figure, is why have a switch statement? It does nothing except fall
> straight through to the default case.

No, the other cases are hidden inside the IF statement.  That's the part I
really don't like because it breaks the block structuring in a non-obvious
way.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\17@103430 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> In this particular case (and without evidence to the contrary) I agree.
> But note that the original Duff's device increased the speed of some
> program from unacceptable to good. Anyone who comes up with something
> like this to save the day for his company deserves prise.

But then it should be accompanied with extra documentation explaining what's
going on.  All too often I see people writing code like that just because
they can and because they think it's cool to use the standard constructs in
novel ways, and it's a plus that others have to "figure out" what the code
does.  Those are the programmers that I want to make mailroom attendents and
burger flippers of.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\17@105221 by William Chops Westfield

face picon face

On Feb 16, 2005, at 11:26 PM, Wouter van Ooijen wrote:

>
>>     switch  (n)
>>         default::
>>             if (isprime(n))
>>                 case 2: case 3: case 5: case 7: p = 1;
>>             else
>>                 case 4: case 6: case 8 case 9: : p=0;
>>
>>
I am SO glad that these days one can trust a compiler to generate
equivalently efficient code from:
       switch(n) {
          case 2: case 3: case 5: case 7:
                 p = 1;
             break;
          case 4: case 6: case 8: case 7:
             p = 0;
                 break;
       default:
                  if (isprime(n))
                         p = 1;
                  else
                         p = 0;
      }

Although the default case in both cases is improved with;
       p = isprime(n)

BillW

2005\02\17@110214 by William Chops Westfield

face picon face

On Feb 17, 2005, at 4:50 AM, John J. McDonough wrote:

>
> Today there are about a million OO languages.  The only ones that get
> used
> to any extent are C++ and VB, and the only one that gets used for OO
> development is C++.

JAVA?

BillW

2005\02\17@110255 by Michael Rigby-Jones

picon face
{Quote hidden}

Only if you know for sure that isprime() returns only 1 and 0 of course.
The switch statement would be much better being within the isprime()
function, if the cost of the few extra call/return cycles could be
spared.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\02\17@112441 by William Chops Westfield

face picon face

On Feb 17, 2005, at 5:14 AM, John J. McDonough wrote:

> Ahh PIP ... how did we ever loose that gem.  On today's bloated
> operating systems we need half a dozen or a dozen commands to
> replace the simple and elegant PIP.

Hmm.  Come to think of it, it's been re-invented for the tiny
unix systems in the form of things like "busybox", right down
to the tops-10-ism of having a bunch of system 'commands' that
invoke it and cause different operations...

BillW

2005\02\17@113336 by Alan B. Pearce

face picon face
>> I would agree with your assessment, but the other part that I
>> cannot figure,
>> is why have a switch statement? It does nothing except fall
>> straight through
>> to the default case.
>
>It doesn't for the numbers 0..9.

Hang on, there is no mention of code between the switch, and the default, so
I imagine that is all empty. Hence the switch statement will generate a
label to the default, which will always be executed, and in my mind the code
generated by the switch statement should be optimised out by the compiler
for this reason. Hence the code becomes an if ... else ... construct only,
which as Wouter noted handles 0..9. There is no code to handle cases outside
these numbers at all.

what have I missed ?

Bob said
>And, you are also right about the mailroom reassignment.

You mean the originator of the code did get re-assigned, or did you wish he
had been :))

2005\02\17@113506 by Harold Hallikainen

face picon face
When I studied C in school, I didn't like the "just another language"
approach. I wanted to know more about memory allocation (where are
automatic variables stored? where are statics stored? Globals? parameter
passing?). I think that knowing this gives a better understanding of the
language and what it's doing.

For the past couple years, I've been doing most of my new pic projects in
C with the interrupt routines in assembly. It's really nice to just tell
the compiler to do some math operation on a 16 or 32 bit variable and have
it done. Also, the ease of parameter passing, passing return values larger
than 8 bits, automatic variables allowing ram reuse with ease, static
variables within functions instead of globals to avoid variable conflicts,
etc. is REALLY nice! In C for PICs, like MCC18 and others, we DO have
direct access to the hardware (SFRs, etc.). For interrupt code, though,
I'm sticking with assembly for speed and to avoid problems with smashing
some unknown variable locations used in C.

Harold



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

2005\02\17@114125 by Harold Hallikainen

face picon face
Didn't CP/M use PIP?

Harold

{Quote hidden}

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

2005\02\17@114843 by Wouter van Ooijen

face picon face
> But then it should be accompanied with extra documentation
> explaining what's going on.

Of course. Nobody said the code shown wasn't.

> All too often I see people writing code like that
> just because
> they can and because they think it's cool to use the standard
> constructs in
> novel ways, and it's a plus that others have to "figure out"
> what the code
> does.

That is a sure reason to demote (or promote?) a programmer to a position
where he is not allowed to come near to a computer. Probably to a
management position, with an obligation to grow pointy hair :(

Wouter van Ooijen

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


2005\02\17@114854 by Harold Hallikainen

face picon face
Speaking of historic machines, anyone read "Soul of a New Machine?"
(http://isbn.nu/0316491977). As I recall, it was about the development of
a new machine at Data General (?) without management approval. It went on
to become a best seller.

Harold


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

2005\02\17@115324 by Wouter van Ooijen

face picon face
> Today there are about a million OO languages.  The only
> ones that get used
> to any extent are C++ and VB, and the only one that gets used for OO
> development is C++.

I would narrow it a bit down: The only OO language that gets widely used
when run-time performance is very important is C++.

Scratch 'widely' and there are lots of small scale OO languages, for
instance Eiffel and Ada9X.

Scratch 'run-time peformance' and there are the run-time slower OO
languages like Java or Python (who are often programming-time faster!).

Scratch OO and there is just one language, C.

Wouter van Ooijen

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


2005\02\17@115632 by Michael Rigby-Jones

picon face


{Quote hidden}

The compiler can still "see" the case statements, within the switch
block, even though they are within an if-else statement.  FWIW I tried
this in the HiTech PICC compiler and it compiles cleanly and works
correctly ( once the syntax errors are fixed).

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\02\17@120921 by Wouter van Ooijen

face picon face
> Hang on, there is no mention of code between the switch

You seem to assume that the default must be last. IIRC there is no such
requirement in C.

Wouter van Ooijen

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


2005\02\17@122422 by Hazelwood Lyle

flavicon
face
I read that years ago, enjoyed it thoroughly.
I don't recall many technical details from it.

Lyle


>Speaking of historic machines, anyone read "Soul of a New Machine?"
>(http://isbn.nu/0316491977). As I recall, it was about the development of
>a new machine at Data General (?) without management approval. It went on
>to become a best seller.
>
>Harold


2005\02\17@122646 by William Chops Westfield

face picon face

On Feb 17, 2005, at 8:48 AM, Harold Hallikainen wrote:

> Speaking of historic machines, anyone read "Soul of a New Machine?"
> (http://isbn.nu/0316491977). As I recall, it was about the development
> of
> a new machine at Data General (?) without management approval.

I read it way back when.  IIRC, it was DG working (officially) on
their next DEC-competitor, with some of the interesting bits being
not knowing what the next DEC would be like.  I don't recall much
"without management approval", although there was a fair bit of
"sausage-like" nature to the making of a new computer ("It is best
enjoy sausage without knowing too much about how it is made."  Or
something like that.  Also frequently applied to laws.)

BillW

2005\02\17@125636 by Howard Winter

face
flavicon
picon face
Bill,

On Thu, 17 Feb 2005 09:26:43 -0800, William "Chops" Westfield wrote:

>...<
>  there was a fair bit of
> "sausage-like" nature to the making of a new computer ("It is best
> enjoy sausage without knowing too much about how it is made."  Or
> something like that.  Also frequently applied to laws.)

As in: "Anyone who enjoys sausages and respects the law, should never watch either being made" !

Cheers,


Howard Winter
St.Albans, England


2005\02\17@131555 by Bob Ammerman

picon face
{Quote hidden}

The the single statement that follows the 'switch( )' starts with 'default:'
and ends with the semicolon that terminates the else clause of the if.

> Bob said
>>And, you are also right about the mailroom reassignment.
>
> You mean the originator of the code did get re-assigned, or did you wish
> he
> had been :))

Luckily, this is only an example of such evil, and was never actually
perpetrated on anyone.

Bob Ammerman
RAm Systems


2005\02\17@131557 by Bob Ammerman

picon face

> When I studied C in school, I didn't like the "just another language"
> approach. I wanted to know more about memory allocation (where are
> automatic variables stored? where are statics stored? Globals? parameter
> passing?). I think that knowing this gives a better understanding of the
> language and what it's doing.

Amen!

It is for this reason that I insisted that my 14 year old son understand
hardware/machine architecture/machine language before he learned assembly.
And that he learn assembly before HLL's.

Bob Ammerman
RAm Systems



2005\02\17@132103 by Bob Ammerman

picon face
> Didn't CP/M use PIP?
>
> Harold

Yep!


2005\02\17@132105 by Bob Ammerman

picon face
> Speaking of historic machines, anyone read "Soul of a New Machine?"
> (http://isbn.nu/0316491977). As I recall, it was about the development of
> a new machine at Data General (?) without management approval. It went on
> to become a best seller.
>
> Harold

Great book. I was working for Data General at the time. The machine in
question was the MV/8000, Data General's answer to the VAX. It was not built
without management approval, but rather was considered an extremely critical
project for the computer.

Bob Ammerman
RAm Systems



2005\02\17@133820 by Harold Hallikainen

face picon face
I guess I remember the book incorrectly. I thought I remembered it being a
"skunk works" project. Oh well.... It's been a few years. I recently saw
several copies of the book in a local used book store.

HH

{Quote hidden}

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

2005\02\17@134437 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Bob Ammerman" <spamBeGonerammermanSTOPspamspamEraseMEverizon.net>
Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?


> > Didn't CP/M use PIP?
> >
> > Harold
>
> Yep!

But there was somedifference.  I don't recall just what it was, but I
remember struggling with CP/M's PIP at a time when PDP PIP was second
nature.

--McD


2005\02\17@140624 by Wouter van Ooijen

face picon face
> Speaking of historic machines, anyone read "Soul of a New Machine?"

Of course, 3 times. One of the classics in computer mythology (in the
good sense). Others:
- the hypothetical man-month
- peopleware
- a history of programming languages
- design and evolution of C++
- psychology of computer programming

Wouter van Ooijen

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


2005\02\17@140641 by Peter L. Peres

picon face


On Thu, 17 Feb 2005, John J. McDonough wrote:

> ----- Original Message -----
> From: "Hulatt, Jon" <KILLspamjon.hulattspamBeGonespammonster.com>
> Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?
>
>
>> Don't forget .NET's new one- C# , and of course Java. Some cynics might
>> argue that C# is Microsoft Java. But not me, no. Anyway, both have a
>> massive enterprise userbase

Is this the same C# that was compared with Perl, Sather, Python and a
couple of others nearly 10 years ago in Byte Magazine (and not at all
originated by ms), and is implemented as a front end in the GNU gcc
compiler that comes standard with Linux ?

Peter

2005\02\17@140647 by Peter L. Peres

picon face


On Thu, 17 Feb 2005, Alan B. Pearce wrote:

> what have I missed ?

It helps if you think of each case inside the switch block as the target
label of a goto. These need not be in order (including not the default
case). The jump-to-a-case is decided at switch(). The OP used
indentation to confuse the enemy ;-) If you rewrite the code with proper
indentation (all cases and default at the same i. level), and keep in
mind that they are in fact target labels for a goto/jump table decided
in switch() it will likely be clearer.

Peter

2005\02\17@140705 by Peter L. Peres

picon face


On Thu, 17 Feb 2005, Harold Hallikainen wrote:

> Didn't CP/M use PIP?

I have used CP/M and there was no PIP. CP/M is very much like DOS, with
REN, DEL, COPY and a few others, as well as familiar device names (CON:
PRN: etc).

Peter

2005\02\17@141611 by Walter Banks

picon face
There are two alternatives that can save some code.
Any compiler supporting C99 could declare p as _Bool
and that would force a 1/0 result
or
p = isprime(n) == 1;

w..

Michael Rigby-Jones wrote:

{Quote hidden}

2005\02\17@145037 by Mark Scoville

flavicon
face
Are you sure there was no PIP in CP/M? I remember using PIP on a Kaypro10
back in the early 80s - I'm pretty sure it ran CP/M. Maybe I'm remembering
wrong.

-Mark

> {Original Message removed}

2005\02\17@150939 by Bob Ammerman

picon face
>> > Didn't CP/M use PIP?
>>
>> I have used CP/M and there was no PIP. CP/M is very much like DOS, with
>> REN, DEL, COPY and a few others, as well as familiar device names (CON:
>> PRN: etc).
>>
>> Peter

Sorry Peter, you are wrong. CP/M did indeed include PIP. The familiar device
names were in CP/M, however.

Now, there were some other shells (command processors) available for CP/M
besides the CCP (console command program) that came with CP/M. Perhaps you
were using one of those and it provided theREN, DEL, COPY, etc. commands.

Bob Ammerman
RAm Systems


2005\02\17@151201 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Mark Scoville" <EraseMEmscovillespamEraseMEunicontrolinc.com>
Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?


> Are you sure there was no PIP in CP/M? I remember using PIP on a Kaypro10
> back in the early 80s - I'm pretty sure it ran CP/M. Maybe I'm remembering
> wrong.

I clearly remember PIP in CP/M, but after reading Peter's post, I seem to
remember the DOS-style commands, too.  I also remember there was something
very strange about the CP/M PIP, But I can't recall what it was.  Perhaps
CP/M PIP was limited in some way ... maybe only for copying between devices?

--McD


2005\02\17@151744 by Richard.Prosser

flavicon
face

Sorry, the version of CP/M I used definately did have it.

Can't remember the exact sysntax but IIRC it was 'reversed" from the file
copy case.

DOS , or probably more correctly QDOS (Quick & Dirty operating system) was
designed to be CP/M "like" in its command line instructions.
For some reason PIP was not carried through into DOS - possibly because it
was a program call rather than a command instruction?

RP






On Thu, 17 Feb 2005, Harold Hallikainen wrote:

> Didn't CP/M use PIP?

I have used CP/M and there was no PIP. CP/M is very much like DOS, with
REN, DEL, COPY and a few others, as well as familiar device names (CON:
PRN: etc).

Peter

2005\02\17@162600 by Jinx

face picon face
>> to any extent are C++ and VB, and the only one that gets used for OO
>> development is C++.

> I would narrow it a bit down: The only OO language that gets widely used
> when run-time performance is very important is C++.

I know next to nothing about C or C++. Why would Bjarne Stroustrup

http://www.research.att.com/~bs/homepage.html

say -

"C makes it easy to shoot yourself in the foot ; C++ makes it harder,
but when you do, it blows away your whole leg."

2005\02\17@162916 by Dave Tweed

face
flavicon
face
Peter L. Peres <@spam@plp@spam@spamspam_OUTactcom.co.il> wrote:
> On Thu, 17 Feb 2005, Harold Hallikainen wrote:
> > Didn't CP/M use PIP?
>
> I have used CP/M and there was no PIP.

Then you weren't paying attention. PIP is one of the ten standard
"transient" commands that comes in a stock distribution of CP/M 2.2.

Bonus points: Who can name the other nine, as well as the five built-in
CCP commands?

> CP/M is very much like DOS, with REN, DEL, COPY and a few others,
> as well as familiar device names (CON: PRN: etc).

I think most of us would prefer if you said that DOS is very much like
CP/M :-).

There is no DEL or COPY in CP/M, except as 3rd-party transient commands.

-- Dave Tweed

2005\02\17@165720 by David Challis

face picon face
OK, a trip through the wayback machine

they are:

STAT
ASM
LOAD
DDT
PIP
ED
SYSGEN
SUBMIT
DUMP
MOVCPM

CCP Builtins:
ERA (erase)
DIR (list directory)
REN (rename)
SAVE (save memory to file)
TYPE (type the file contents)

Dave Challis

{Original Message removed}

2005\02\17@171635 by Harold Hallikainen

face picon face
Wanna run CP/M on your Windoze (DOS) machine?  Try Z*)MU!

Describing the first of a two-part series of 8080, Z80, and CP/M
    emulators for the IBM PC. This document describes Z80MU (version 2.1,
                                                      Z80MU
    dated 10/30/85), a software emulation of the Z80 and CP/M 2.2.  The
    second product - if it ever gets out the door - includes hardware
    emulation of the 8080, using the NEC V20 8088-compatible processor
    chip.

    Program written by Joan Riff for Computerwise Consulting Services.


Harold



{Quote hidden}

> {Original Message removed}

2005\02\17@174440 by Dave Tweed

face
flavicon
face
Peter L. Peres <spamBeGoneplpspamKILLspamactcom.co.il> wrote:
> CP/M is very much like DOS, with REN, DEL, COPY and a few others,
> as well as familiar device names (CON: PRN: etc).

I just double-checked: There is no PRN: device in CP/M, either,
although the assembler produces its listings with a .PRN extension.

The logical printer device is known as LST: and the physical printer
is known as LPT:.

However, the (non-existant?) PIP command implements a virtual device
called PRN: which is the same as LST: except that tabs are expanded
to 8 columns, lines are numbered and there a page break every 60 lines.

E.g.:

  STAT LST:=LPT:               assign logical to physical device
  PIP PRN:=GAME.PRN            print the result of "ASM GAME"
  PIP LST:=GAME.PRN[nt8p60]    same as previous command

-- Dave Tweed

2005\02\17@174748 by Russell McMahon

face
flavicon
face
> ... Try Z*)MU!

Error: Compile error 89.3.2(a)
Error: 44.56    Unknown CPU type
Error: 23.9a    Run aborted
Warning: 303.23    Core temperature exceeds speficied parameters.
Warning: 666.66    Core integrity probable within *).3*) Nanosecond
Warni



2005\02\17@181218 by Harold Hallikainen

face picon face
Gotta watch that shift key! It's Z80MU!

HH

>> ... Try Z*)MU!
>
> Error: Compile error 89.3.2(a)
> Error: 44.56    Unknown CPU type
> Error: 23.9a    Run aborted
> Warning: 303.23    Core temperature exceeds speficied parameters.
> Warning: 666.66    Core integrity probable within *).3*) Nanosecond
> Warni
>

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

2005\02\17@201400 by Roy Ward

flavicon
face
Wouter van Ooijen wrote:

>>Speaking of historic machines, anyone read "Soul of a New Machine?"
>>    
>>
>
>Of course, 3 times. One of the classics in computer mythology (in the
>good sense). Others:
>- the hypothetical man-month
>  
>
I'm pretty sure that's "The Mythical Man-Month"

>- peopleware
>- a history of programming languages
>- design and evolution of C++
>- psychology of computer programming
>
>Wouter van Ooijen
>  
>
Oh, and I've read "Soul of a New Machine" too - really enjoyed it, and
pleased I don't have to work under that sort of pressure :)

Cheers,
Roy Ward.

2005\02\17@203632 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Roy Ward" <.....roywardspam_OUTspamphysics.otago.ac.nz>
Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?


> I'm pretty sure that's "The Mythical Man-Month"

I noticed that too, but I figured the Dutch language has very few words, and
probably their word for mythical and hypothetical is the same.

--McD


2005\02\17@210247 by Russell McMahon

face
flavicon
face
>>>Speaking of historic machines, anyone read "Soul of a New Machine?"

Excellent story.
There are similar books in other disciplines that are equally worth
reading, even if you are not involved i that industry. I'll cite
several here - names are inexact in several cases. if anyone is
especially interested, and Google doesn't help, ask and I'll refine
the titles.

Engineers (and many others) are unlikely to regret having spent the
time taken to read these books.

"The ??macleans?? Story" - Brylcreem, toothpaste and more.
Fascinating.
More a business development story than an engineering one but useful
and fun.

The IBM 360 story. Also fascinationg.

"The Sun, the Stirling Engine and the drive to save the world" (title
is a pun). Excellent story very much in the vein of "soul of a new
machine". Set in Sunpower as they strive to produce a 10 kW plus solar
dish driven Stirling engine for a contract.

"Ignition! - An informal history of liquid rocket propellants"
An utterly superb read, even if rockets are only of very vague
interest. DON'T buy the overpriced, print-on-demand reprint with the
shonky pictures. OK to read I guess. Libraries will hage the original.

The Boeing 747 story - with a complete history from day one to the
747.
Well worth reading.

"The seven sisterss"    The oil giants story. Far less target friendly
than the above, but worth the read.

Different but ...
"Try anything twice".
?? Young. Autobiography of the man who wrote "Rommel" before anyone
else thought to.
Unbelievable (but probably mostly true).




       RM

2005\02\17@224515 by Sergio Masci

flavicon
face

----- Original Message -----
From: Jinx <TakeThisOuTjoecolquitt.....spamTakeThisOuTclear.net.nz>
To: Microcontroller discussion list - Public. <TakeThisOuTpiclistKILLspamspamspammit.edu>
Sent: Thursday, February 17, 2005 9:25 PM
Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?


{Quote hidden}

C++ allows you to program more defensively than C, making it easier to catch
simple bugs. However this requires that something that looks simple has a hidden
complexity. When you have a bug in this hidden stuff it can be a real bitch to
locate and sometimes an even bigger bitch to correct.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use




2005\02\18@020706 by dr. Imre Bartfai

flavicon
face
On Thu, 17 Feb 2005, John J. McDonough wrote:

> ----- Original Message -----
> From: "Mark Scoville" <.....mscovillespamRemoveMEunicontrolinc.com>
> Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?
>
>
>> Are you sure there was no PIP in CP/M? I remember using PIP on a Kaypro10
>> back in the early 80s - I'm pretty sure it ran CP/M. Maybe I'm remembering
>> wrong.
>
> I clearly remember PIP in CP/M, but after reading Peter's post, I seem to
> remember the DOS-style commands, too.  I also remember there was something
> very strange about the CP/M PIP, But I can't recall what it was.  Perhaps
> CP/M PIP was limited in some way ... maybe only for copying between devices?
>
> --McD
Maybe it was that strangeness if PIP was called without command line
arguments then it entered into dialog mode where one could type that
cmdline parms which then were interpreted immediately. Alternatively,
PIP accepts as many parms as fit and every of them acts as a stand-alone
command. BTW I have a CP/M PIP linked with a CP/M emulator which in turn
runs under DOS so I can run it also nowadays (I do it seldom).

Imre

2005\02\18@024847 by Wouter van Ooijen

face picon face
> "C makes it easy to shoot yourself in the foot ; C++ makes it harder,
> but when you do, it blows away your whole leg."

C has some simple constructs for shooting yourself in the foot:
- out-of-bounds array access
- invalid pointers
- unchecked paramter passing
- typecasts

C++ *keeps* those constructs, but offers alternatives for nearly all
places where you would have to use C constructs which (when used wrong)
might cause you to shoot you in the foot. But C++ adds a number of very
complex new ways to nuke yourself, for instance related to the (class)
variable allocation and initialisation.

But a paraphrase on Godel: I have yet to see a programming language that
is powerfull enough for general work, yet does not make it possible to
shoot yourself in the foot.

Wouter van Ooijen

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


2005\02\18@024847 by Wouter van Ooijen

face picon face
> >- the hypothetical man-month

> I'm pretty sure that's "The Mythical Man-Month"

Ok, ok, I admit it was many years ago. But I have it somewhere on a
bookshelve, or maybe still in a box from the last home change, or was it
the one before?

Wouter van Ooijen

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


2005\02\18@024847 by Wouter van Ooijen

face picon face
> C++ allows you to program more defensively than C, making it
> easier to catch
> simple bugs. However this requires that something that looks
> simple has a hidden
> complexity. When you have a bug in this hidden stuff it can
> be a real bitch to
> locate and sometimes an even bigger bitch to correct.
>
> Regards
> Sergio Masci
> http://www.xcprod.com/titan/XCSB

What did you use to write XCSB in? Jal was/is in C, but if I ever write
Jal++ it will probably be in C++.

Wouter van Ooijen

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


2005\02\18@071530 by Gerhard Fiedler

picon face
Peter L. Peres wrote:

>>> Don't forget .NET's new one- C# , and of course Java. Some cynics might
>>> argue that C# is Microsoft Java.

> Is this the same C# that was compared with Perl, Sather, Python and a
> couple of others nearly 10 years ago in Byte Magazine (and not at all
> originated by ms), and is implemented as a front end in the GNU gcc
> compiler that comes standard with Linux ?

Probably not. I don't know that C# that you are talking about, but
Microsoft's C# is based on the .NET VM (something quite similar in concept
to the Java VM).

Gerhard

2005\02\18@095109 by Sergio Masci

flavicon
face
> What did you use to write XCSB in? Jal was/is in C, but if I ever write
> Jal++ it will probably be in C++.
>
> Wouter van Ooijen

XCSB was written in C++

Would JAL++ be OO? What kind of features would you like to implement in JAL++?
Have you considered generating high level source like the original C++ compiler
(for anyone that is not aware the original C++ compiler generated C source). In
some cases XCSB generates high level statements that the XCASM assembler
converts to optimised assembler (XCASM is a meta assembler that supports high
level constructs like those discussed earlier in this thread).

e.g.
the XCSB statements

       int    a, b[5], j
       a = b[j] + b[j+1]

get converted to the XCASM statements

       .sect    some_data_section
       a    .dsw    1
       b    .dsw    5
       j    .dsw    1

       .sect    some_code_section
       .let    a = b[j] + b[j+1]


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\02\18@104658 by Wouter van Ooijen

face picon face
> Would JAL++ be OO?

Depends on your definition. I don't believe in virtual functions on the
type of microcontrollers Jal is targeting, so there won't be run-time
polymorphism.

> What kind of features would you like to implement in JAL++?

Better abstraction mechanisms, something like Ada parameterised modules
or C++ templates.

> Have you considered generating high level source

No, I think the compiler should have full control over what is
generated. I have been dreaming about a construct that I'd like at least
in theory be able to implement: fixed-timing programming. This
definitely requires full control over the generated code.

Wouter van Ooijen

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


2005\02\18@141415 by Peter L. Peres

picon face

On Thu, 17 Feb 2005, Mark Scoville wrote:

> Are you sure there was no PIP in CP/M? I remember using PIP on a Kaypro10
> back in the early 80s - I'm pretty sure it ran CP/M. Maybe I'm remembering
> wrong.

I still have a CP/M book and I do not remember any PIP in it, but it is
in it (I just looked, DIP,PIP,STAT,XDIR,D)!

Peter

2005\02\18@141419 by Peter L. Peres

picon face

On Fri, 18 Feb 2005, Jinx wrote:

>>> to any extent are C++ and VB, and the only one that gets used for OO
>>> development is C++.
>
>> I would narrow it a bit down: The only OO language that gets widely used
>> when run-time performance is very important is C++.
>
> I know next to nothing about C or C++. Why would Bjarne Stroustrup
>
> http://www.research.att.com/~bs/homepage.html
>
> say -
>
> "C makes it easy to shoot yourself in the foot ; C++ makes it harder,
> but when you do, it blows away your whole leg."

Probably because C++ is more terse than C and at the same time allows
overloading *any* operator and more. As an example, you can declare the
'+' operator to actually be '-' when used with certain types of data.
Additionally, in C++ the compiler is supposed to 'guess' which function
definition applies best to what the programmer said if the latter is not
fully qualified to a namespace. The result can be very interesting.

Peter

2005\02\18@141430 by Peter L. Peres

picon face


On Thu, 17 Feb 2005, Bob Ammerman wrote:

>> Didn't CP/M use PIP?
>>
>> Harold
>
> Yep!

Which version of CP/M ?

thanks,
Peter


2005\02\18@141435 by Peter L. Peres

picon face


On Thu, 17 Feb 2005, Bob Ammerman wrote:

{Quote hidden}

The book says that the six commands DIR,ERA,TYPE,REN,SAVE and USER are
available on any CP/M shell since they are implemented in the core (bdos
?). All the other commands are external. DOS command.com kept the same
idea for a long time, but added COPY and changed the syntax of a few
commands.

And you are right, there is PIP, implemented as an external command. I
did not use CP/M enough to become an expert at it.

Peter

2005\02\18@141441 by Peter L. Peres

picon face


On Fri, 18 Feb 2005 RemoveMERichard.ProsserspamspamBeGonePowerware.com wrote:

> DOS , or probably more correctly QDOS (Quick & Dirty operating system) was
> designed to be CP/M "like" in its command line instructions.
> For some reason PIP was not carried through into DOS - possibly because it
> was a program call rather than a command instruction?

Maybe it did not carry over but it did appear sort of laterally as the
pipe character I think. Was the pipe character used before CP/M and Unix
?

Peter

2005\02\18@141446 by Peter L. Peres

picon face


On Thu, 17 Feb 2005, Dave Tweed wrote:

{Quote hidden}

I won't compete, the book is open on my table now ;-).

>> CP/M is very much like DOS, with REN, DEL, COPY and a few others,
>> as well as familiar device names (CON: PRN: etc).
>
> I think most of us would prefer if you said that DOS is very much like
> CP/M :-).
>
> There is no DEL or COPY in CP/M, except as 3rd-party transient commands.

I think that the version I used was a 'hacked' distribution - probably
rewritten by a genius from some of the local IT institutions (I was
behind the iron curtain at the time). I understand that some places in
the ex-USSR there still are CP/M machines in schools and such.

Peter

2005\02\18@141452 by Peter L. Peres

picon face


On Thu, 17 Feb 2005, John J. McDonough wrote:

> I clearly remember PIP in CP/M, but after reading Peter's post, I seem to
> remember the DOS-style commands, too.  I also remember there was something
> very strange about the CP/M PIP, But I can't recall what it was.  Perhaps
> CP/M PIP was limited in some way ... maybe only for copying between devices?

PIP syntax for CP/M from my ancient book (printed in 198x on low
quality paper):

PIP dst=src1 [opt], src2 [opt]

Options are: B (block mode), Dn (truncate lines to n characters), F
(kill FF chars), Gn (read user source code ??), H (hex copy checking
syntax), I (ignore records that start with :00, implies H - this would
load an INHX8 hex file dropping the lines that would overwrite the TPA
which was 0x0000-0x00FF absolute address), L (lowercase), N (number
lines), O (copy object files (binary)), Pn (add FF every n lines), Qs^Z
(stop copy when string 's' seen, ^Z terminates the string when input
by user), Ss^Z (start copy when seeing 's'), Tn (expand TABs to n
spaces), U (uppercase), V (check copy), Z (zero P bit of each copied
byte),

Not so strange compared to *nix commands (which use all alphabet letters
twice - once uppercased and once lowercased for options).

I remember DIP now, it was used to copy files using only one drive.

Peter

2005\02\18@141641 by Peter L. Peres

picon face


On Thu, 17 Feb 2005, Harold Hallikainen wrote:

> Wanna run CP/M on your Windoze (DOS) machine?  Try Z*)MU!

this may likely help people looking for cp/m emulators:

http://www.retroarchive.org/cpm/cdrom/SIMTEL/CPMUG/00README.TXT

inevitably there is an open source version (with source and everything,
runs on linux and many other *x things), yaze, by Michael Haardt
(emulates CP/M 3.0).

There are many others.

Peter



2005\02\18@145400 by Peter L. Peres

picon face


On Fri, 18 Feb 2005, Gerhard Fiedler wrote:

{Quote hidden}

Ok, now you got me started. I dug my copy of the magazine out, it was
Dr. Dobb's Journal, #206, October 1993, Which features the title page:

"Beyond C++,
Considering the Alternatives
* C+@
* Sather
* Parasol
* Liana
* Beta
* Eiffel"

there is also an article called "networking with Perl (in 1993!)"

so it was my time machine that was broken again. But:

the article on C+@ is on page 24, by Jim Fleming, and says that:

"C+@ is derived from C++ and Smalltalk ... and was started at the same
time as C++, but derived from the Calico language developed at Bell
Labs' ... 'C+@ was designed to be a confortable companion language to C
and C++, rather than an extension to C. It retains C's expression syntax
and control statements. C functions and data objects can be accessed
directly from C+@. ... The complete C+@ graphical development
environment is written in C+@ ... a GUI builder is included for quickly
building applications ... C+@ can also be used in command-line mode ...
applications can be moved between platforms without recompiling, from
Sparc to 68k to Ix86 ... C+@ is not interpretative - the binaries are
encoded using a sophisticated "beading" technique (my note: the term VM
did not yet exist in this context) ... for the past EIGHT YEARS (my
emphasis: we are in 1993, that means 1993-8=1985), C+@ has been evolving
and has reached a state where AT&T has decided to release it to the
commercial world."

Examples of C+@ are provided in the article. It looks a lot like C# to
me (I do not know a lot of C# - only occasional use) - but so do other
C?? flavors.

SO my wetware time machine is not so bad, the context of the article
seems to say C# may have been inspired by C+@ among other things.

Peter


2005\02\19@082428 by Gerhard Fiedler

picon face
>> Have you considered generating high level source
>
> No, I think the compiler should have full control over what is
> generated. I have been dreaming about a construct that I'd like at least
> in theory be able to implement: fixed-timing programming. This
> definitely requires full control over the generated code.

While we're at it, and two compiler writers are discussing about useful
features, John Payson came up with an interesting idea in the Htsoft forum
http://www.htsoft.com/forum/all/showflat.php/Cat/0/Number/15352/an/0/page/0#15352

Basically, it is a compiler that can generate both compiled code (fast) and
interpreted (small) code. The programmer can mark every function that
should be interpreted, and it would transparently be compiled differently
(into something like a p code that then gets interpreted by a runtime
engine). I found the thought intriguing.

Gerhard

2005\02\19@083705 by Gerhard Fiedler

picon face
Peter L. Peres wrote:

{Quote hidden}

They didn't mention Python (but you did at first). I never had the pleasure
to do extensive programming in Python, but whenever I look at a C or C++ or
C# or Java or Pascal or Delphi program, I wonder why they don't use the
block building by indentation that Python uses.

Everybody indents code according to the block structure, and the
differences people get in each others' hairs about are almost only about
where to place the braces (in C dialects :). No braces or other block
terminators needed in Python. Of course a few C constructs wouldn't be
possible with this, and maybe I should take C (as a high-level assembler)
out of this list, but for the other languages this would only feel so
natural.


> SO my wetware time machine is not so bad,

I bet not :)

> the context of the article seems to say C# may have been inspired by C+@
> among other things.

Interesting language. There are so many out there that never make it into
the public light... I mean /large/ public.

Gerhard

2005\02\19@091408 by Wouter van Ooijen

face picon face
> Basically, it is a compiler that can generate both compiled code
> (fast) and interpreted (small) code. The programmer can mark
> every function that should be interpreted, and it would
> transparently be compiled differently (into something like a
> p code that then gets interpreted by a runtime
> engine). I found the thought intriguing.

It is an interesting idea, and of course I have been thinking about this
for years. But I could not find a clear way to do it 'right'. Problems
are:

- If you can have P-code in the PICs Flash you surely also want the
option to have P-code in the PIC EEPROM, and why not in an external
EEPROM? And why not in another external medium?

- It is not trivial to define a (P-)code that is more compact than PIC
assember for bit and byte operations.

- A two-way choice for a programmer (fast/large versus slow/compact)
seems a bit restricted, and very vague. How slow is acceptable? A factor
10 slower than normal PIC code? A factor 10000?

Wouter van Ooijen

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


2005\02\19@103100 by olin_piclist

face picon face
Gerhard Fiedler wrote:
> Everybody indents code according to the block structure, and the
> differences people get in each others' hairs about are almost only
> about where to place the braces (in C dialects :). No braces or other
> block terminators needed in Python. Of course a few C constructs
> wouldn't be possible with this, and maybe I should take C (as a
> high-level assembler) out of this list, but for the other languages
> this would only feel so natural.

I haven't looked at Python (and don't plan on it since it's apparently just
an interpreter), so I don't know how its block structure really works.

Block scope by indentation is an interesting idea, but I see one problem
with it.  I indent Pascal according to block nesting too, but sometimes I
cheat because otherwise the left end of the line would be too far to the
right and there wouldn't be enough room for a meaningful comment after most
lines.  In those cases I jump back to no indentation level and continue
indenting from there, then jump back when the level pops back to where it
was.  This is usually done at major breaks where there is a paragraph
comment anyway.

Another place I do this routinely is in the cases of a CASE statement (like
a SWITCH statement in C).  Often each case has a paragraph comment in front
of it, and it's just easier and looks nicer if the block of code to process
a particular command, for example, starts with no indentation.  The
indentation is then restored at the end of the CASE statement.

As long as there is an indentation escape mechanism, nesting by indentation
seems like a good idea, at least without having tried it.  A deliberate
indentation adjust statement would be sufficient.  Something like UNDENT 5
would tell the compiler that the source code will now be written with 5
nesting levels less although the real nesting level won't change.  This
would be followed by INDENT 5, or maybe just INDENT, to restore the level.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\19@134733 by Byron A Jeff

face picon face
On Sat, Feb 19, 2005 at 03:14:10PM +0100, Wouter van Ooijen wrote:
> > Basically, it is a compiler that can generate both compiled code
> > (fast) and interpreted (small) code. The programmer can mark
> > every function that should be interpreted, and it would
> > transparently be compiled differently (into something like a
> > p code that then gets interpreted by a runtime
> > engine). I found the thought intriguing.
>
> It is an interesting idea, and of course I have been thinking about this
> for years.

As have I. My NPCI compiler has been stalled the last 4 years or so.
It's built around this concept.

> But I could not find a clear way to do it 'right'. Problems
> are:
>
> - If you can have P-code in the PICs Flash you surely also want the
> option to have P-code in the PIC EEPROM, and why not in an external
> EEPROM? And why not in another external medium?

No reason. I took care of that by integrating a gettoken function in
the interpreter. It doesn't care where the code comes from. I have two
implementations: fetch from internal program memory and fetch from
external serial EEPROM. Both worked the last time I was actively working
on it.

> - It is not trivial to define a (P-)code that is more compact than PIC
> assember for bit and byte operations.

I never saw compactness as the primary goal of P-Code. When I started
NPCI ICD, bootloaders, and senf programming PICs didn't exist. So the
infrastructure for painless development didn't really exist.

The second goal was to introduce some useful features directly into
the high level language. NPCI has direct bit manipulation, multilevel
breaks/continues, and a restructured parameter passing system that
obviates the initial need for pointers.

The third was to have a cross platform way of programming at the micro
level. That's what Basic and C compilers really bring to the table.

And finally was the issue below.
>
> - A two-way choice for a programmer (fast/large versus slow/compact)
> seems a bit restricted, and very vague. How slow is acceptable? A factor
> 10 slower than normal PIC code? A factor 10000?

Point is that you provide a mechanism and then allow the programmer
to choose the implementation policy.

NPCI used the concept of assembly procedures. Specific function could
be written into the interpreter and called from the NPCI program. I used
a checksum mechanism that verified that the assembly procedures were in
fact integrated into the interpreter before running the program.

It wasn't perfect by any stretch. But it did facilitate handling the
broad issue of the fact that the vast majority of cycles in a program
are executed by a limited amount of code. I believe the Mythical Man
Month called it the 90/10 Rule. So the speed/time sensitive stuff
could be written into the interpreter.

But it may all be moot now. With a good compiler and a good bootloader
or ICD or ICSP, one can develop high level languages completely compiled
with the same ease as interpreted languages. So unless you're trying to
meet one of the other goals, then it may simply no be worth it anymore.

BAJ

2005\02\19@142735 by Wouter van Ooijen

face picon face
> No reason. I took care of that by integrating a gettoken function in
> the interpreter.

Now can I write, in your language, in a single program, both the code to
accesses the external storage device, and the code that is to be
translated to be P-code? And what does the output look like, one hex
file for the pic and another one for the external storage device?

> Point is that you provide a mechanism and then allow the programmer
> to choose the implementation policy.

That is not nearly enough fir me to feel 'good'. The programmer does not
need a choice, he needs control over then end effect. Somthing like
'this code should run within 100us', or 'this code must not take more
than 3000 instructions (bytes? words?)'. What this means in terms of
real code / interpreted code can depend on the target (for instance the
processor speed).

Wouter van Ooijen

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


2005\02\19@203821 by Byron A Jeff

face picon face
On Sat, Feb 19, 2005 at 08:27:34PM +0100, Wouter van Ooijen wrote:
> > No reason. I took care of that by integrating a gettoken function in
> > the interpreter.
>
> Now can I write, in your language, in a single program, both the code to
> accesses the external storage device, and the code that is to be
> translated to be P-code?

I don't think so. NPCI does a 100% translation into NPCI bytecode. I'm
saying that an arbitrary gettoken function can be written to access that
bytecode.

The interpreter accesses the external storage device.

> And what does the output look like, one hex
> file for the pic and another one for the external storage device?

A single hexfile with the NPCI bytecode. At the time I was last working
on it I had built a serial EEPROM programmer out of a 16F84 that would
program the external serial EEPROM. It also had a back debugging channel.


{Quote hidden}

Interesting point. So you want the compiler to give auto diagnostics as
to the speed/size of certain code sections?

I guess that would require some type of profiling support. That could be
added to the interpreter for the speed.

However I'm not sure if the code is isosyncronous in the interpreter,
especially if you have busy waiting.

Like I said an interesting point.

BAJ

2005\02\19@222928 by Sergio Masci

flavicon
face
Gerhard Fiedler wrote:

> >> Have you considered generating high level source
> >
> > No, I think the compiler should have full control over what is
> > generated. I have been dreaming about a construct that I'd like at least
> > in theory be able to implement: fixed-timing programming. This
> > definitely requires full control over the generated code.
>
> While we're at it, and two compiler writers are discussing about useful
> features, John Payson came up with an interesting idea in the Htsoft forum
>
www.htsoft.com/forum/all/showflat.php/Cat/0/Number/15352/an/0/page/0#1535
2
>
> Basically, it is a compiler that can generate both compiled code (fast) and
> interpreted (small) code. The programmer can mark every function that
> should be interpreted, and it would transparently be compiled differently
> (into something like a p code that then gets interpreted by a runtime
> engine). I found the thought intriguing.
>
> Gerhard

The only real problem that I can see with this is the relatively huge overhead
of providing an interpreter. For a small device like a PIC I think that the net
gain would be small and cost considerable effort. An alternative would be an
optimising compiler that is geared towards generating compact code instead of
efficient code. XCSB generates compact executables as a SIDE EFFECT of trying to
generate efficient code. It could generate much more compact code if efficiency
were not an issue but in some cases it would takes several times as long to
execute.

An important point to consider is that larger programs often require more
runtime variables than smaller programs. Simply increasing the size of the code
section of a program may still fail to yield a bigger program because the
variable requirements (RAM) are harder to meet.

Anyway a good method of implementing a mixed compiled / interpreted executable
would be to use function calls in place of tokens and embed data after the call.
However this would require the ability to access and modify the return address
which cannot be done using the "call" instruction of the 14 bit PICs. An
alternate call mechanism (such as the XCSB longcall mechanism) could be used but
this is not as efficient as the native "call" instruction. On the 18 series this
probem does not exist.

Using calls as tokens the amount of "interpreter kernel" pulled into the
executable could be controlled by the compiler effectively eliminating those
parts of the interpreter which are not use by the application. The main down
side would be that the interpreted (byte code) could not be held in external
memory.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

2005\02\19@224631 by Sergio Masci

flavicon
face

----- Original Message -----
From: Byron A Jeff <TakeThisOuTbyronspamspamcc.gatech.edu>
To: Microcontroller discussion list - Public. <piclistEraseMEspammit.edu>
Sent: Saturday, February 19, 2005 6:47 PM
Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?


{Quote hidden}

Byron you should persevere. Knowledge and experience are good goals in their own
right. Also here's another: PICs are cheap, you can easiliy pack several on a
small board for very little cost, if you have a compiler that can generate code
that can be executed from an EXTERNAL source you have the potential to build a
system that can pass sections of code between processors. A big program with a
pool of processors executing different parts, possibly modifying sections and
passing them on for further processing, that's a very interesting project.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use



2005\02\19@231705 by Jake Anderson

flavicon
face
> Byron you should persevere. Knowledge and experience are good
> goals in their own
> right. Also here's another: PICs are cheap, you can easiliy pack
> several on a
> small board for very little cost, if you have a compiler that can
> generate code
> that can be executed from an EXTERNAL source you have the
> potential to build a
> system that can pass sections of code between processors. A big
> program with a
> pool of processors executing different parts, possibly modifying
> sections and
> passing them on for further processing, that's a very interesting project.
>
> Regards
> Sergio Masci
>

I wonder if this could be made to be robust, IE some kind of distributed
processing
capablle of having CPU's and random bits pulled at run time and still
opperating.

2005\02\19@233205 by D. Jay Newman

flavicon
face
> Byron you should persevere. Knowledge and experience are good goals in their own
> right. Also here's another: PICs are cheap, you can easiliy pack several on a
> small board for very little cost, if you have a compiler that can generate code
> that can be executed from an EXTERNAL source you have the potential to build a
> system that can pass sections of code between processors. A big program with a
> pool of processors executing different parts, possibly modifying sections and
> passing them on for further processing, that's a very interesting project.
>
> Regards
> Sergio Masci

Ahhh. This is the basic idea of my MAPS project: Multiple Array of PIC'S.

The idea is that an array of very inexpensive microcontrollers should
be able to out perform a normal computer at some tasks.
--
D. Jay Newman           ! Polititions and civilations come and
RemoveMEjayEraseMEspamspam_OUTsprucegrove.com     ! go but the engineers and machinists
http://enerd.ws/robots/ ! make progress

2005\02\20@001554 by Jake Anderson

flavicon
face

if you wanted to look at that
look at the blackfin processors
$4 (1k qty) for a dual core 750 mhz cpu with DSP functions

> {Original Message removed}

2005\02\20@004339 by D. Jay Newman

flavicon
face
> if you wanted to look at that
> look at the blackfin processors
> $4 (1k qty) for a dual core 750 mhz cpu with DSP functions

But the entire idea is to use *very* inexpensive microcontrollers.

I'm thinking something cheaper. Someday. Of course, by then the
cheap processors will be more powerful than they are today.
--
D. Jay Newman           ! Polititions and civilations come and
@spam@jayRemoveMEspamEraseMEsprucegrove.com     ! go but the engineers and machinists
http://enerd.ws/robots/ ! make progress

2005\02\20@022130 by Robert Rolf

picon face
A thousand PICs does not a Mac truck make.
In other words, there are some problems where the problem
can only be solved efficiently with BIG SILICON.
e.g. a million PICs are not going to work too well
processing a 3 million customer database/billing cycle.

D. Jay Newman wrote:

>>if you wanted to look at that
>>look at the blackfin processors
>>$4 (1k qty) for a dual core 750 mhz cpu with DSP functions
>
>
> But the entire idea is to use *very* inexpensive microcontrollers.
>
> I'm thinking something cheaper. Someday. Of course, by then the
> cheap processors will be more powerful than they are today.

2005\02\20@071352 by D. Jay Newman

flavicon
face
> A thousand PICs does not a Mac truck make.
> In other words, there are some problems where the problem
> can only be solved efficiently with BIG SILICON.
> e.g. a million PICs are not going to work too well
> processing a 3 million customer database/billing cycle.

I agree. However, there are some problems that can be broken up
along simple lines (such as those solvable by array processors).

I never said that I wanted to make a general purpose processor.
--
D. Jay Newman           ! Polititions and civilations come and
EraseMEjayspam@spam@sprucegrove.com     ! go but the engineers and machinists
http://enerd.ws/robots/ ! make progress

2005\02\20@073406 by Jake Anderson

flavicon
face
actually billing (can) work *really* well with distributed processing ;->

its linear things that clug stuff up


> {Original Message removed}

2005\02\20@081121 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Jake Anderson" <@spam@grooveeespam_OUTspam.....optushome.com.au>
Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?


> actually billing (can) work *really* well with distributed processing ;->

Yeah, but I'd hate to write the COBOL compiler for a massive array of PICs.

--McD


2005\02\20@091459 by Sergio Masci

flavicon
face
Robert Rolf  wrote:

> A thousand PICs does not a Mac truck make.
> In other words, there are some problems where the problem
> can only be solved efficiently with BIG SILICON.
> e.g. a million PICs are not going to work too well
> processing a 3 million customer database/billing cycle.

A thousand Pentium IVs wont make a Mac truck either :-) But I understand what
you're trying to say and I agree in part.

It's a shame you chose a database as an example of how a fast single processor
can outperform an array since most database applications actually benefit
greatly from multiprocessor architectures. A correctly configured array of 486s
will beat the crap out of an Pentium of the same overall MIPS rating for many
database applications.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\02\20@092653 by Sergio Masci

flavicon
face
D. Jay Newman wrote:


> > if you wanted to look at that
> > look at the blackfin processors
> > $4 (1k qty) for a dual core 750 mhz cpu with DSP functions
>
> But the entire idea is to use *very* inexpensive microcontrollers.
>
> I'm thinking something cheaper. Someday. Of course, by then the
> cheap processors will be more powerful than they are today.

Or maybe manufacturers like MCHIP will wake up to the fact that they can put
several cores into one package to greatly increase performance with minimal
increase in production costs. Imagine a 40 pin  chip (like the 16f877) with
multiple cores inside it. Instant increase in program space, RAM, USARTS, PWM
etc. You could configure one with a really slow clock that could monitor the
outside world while the other cores were sleeping. Ah the possibilities :-)

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\02\20@093554 by Sergio Masci

flavicon
face
D. Jay Newman wrote:

> Ahhh. This is the basic idea of my MAPS project: Multiple Array of PIC'S.
>
> The idea is that an array of very inexpensive microcontrollers should
> be able to out perform a normal computer at some tasks.

I had a look on your site but I couldn't see any info on this. Do you have any
details you'd care to share?

I am planning on adding multiprocessing support to the XCSB compiler. It will
use a virtual clock to syncrhonise functions between processors (in particular
background comms probably with variable bit timing as an option)


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\02\20@094154 by Sergio Masci

flavicon
face
Jake Anderson wrote:

> I wonder if this could be made to be robust, IE some kind of distributed
> processing
> capablle of having CPU's and random bits pulled at run time and still
> opperating.

PICs are cheap, give it a try. I'm sure Byron wouldn't mind you experimenting
with his NPCI compiler.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use




2005\02\20@100304 by D. Jay Newman

flavicon
face
> D. Jay Newman wrote:
>
> > The idea is that an array of very inexpensive microcontrollers should
> > be able to out perform a normal computer at some tasks.
>
> I had a look on your site but I couldn't see any info on this. Do you have any
> details you'd care to share?

No, it's just an idea at present. I'm concentrating all my efforts into
getting my book done that I haven't written MAPS up yet.

The basic idea is an array processor using very low cost/low power devices.
This could be useful for robotic vision among other things.
--
D. Jay Newman           ! Polititions and civilations come and
spamBeGonejayEraseMEspamsprucegrove.com     ! go but the engineers and machinists
http://enerd.ws/robots/ ! make progress

2005\02\20@102721 by Gerhard Fiedler

picon face
Sergio Masci wrote:

>> While we're at it, and two compiler writers are discussing about useful
>> features, John Payson came up with an interesting idea in the Htsoft forum
>>
> http://www.htsoft.com/forum/all/showflat.php/Cat/0/Number/15352/an/0/page/0#15352

> The only real problem that I can see with this is the relatively huge overhead
> of providing an interpreter. For a small device like a PIC I think that the net
> gain would be small and cost considerable effort.

I also thought what Wouter wrote: that possibly the net gain is not that
big, with today's good optimizing compilers. Anyway, it would be something
for the bigger processors.

The other thing Wouter wrote, about control, I think in this case the
control would be the same a programmer has with any interpreted code. It's
less (or it is a bit more complicated to get), but that's interpreters.


> An alternative would be an optimising compiler that is geared towards
> generating compact code instead of efficient code.

Or where the goal can be controlled, by function (or file).


> Using calls as tokens the amount of "interpreter kernel" pulled into the
> executable could be controlled by the compiler effectively eliminating
> those parts of the interpreter which are not use by the application. The
> main down side would be that the interpreted (byte code) could not be
> held in external memory.

I guess the not needed parts of the interpreter could be eliminated even
with standard p code -- keep in mind that in this scenario, the
compiler/linker would generate the interpreter at the same time it
generates the p code.

Gerhard

2005\02\20@103858 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> Gerhard Fiedler wrote:
>> Everybody indents code according to the block structure, and the
>> differences people get in each others' hairs about are almost only
>> about where to place the braces (in C dialects :). No braces or other
>> block terminators needed in Python. Of course a few C constructs
>> wouldn't be possible with this, and maybe I should take C (as a
>> high-level assembler) out of this list, but for the other languages
>> this would only feel so natural.
>
> I haven't looked at Python (and don't plan on it since it's apparently just
> an interpreter), so I don't know how its block structure really works.

FWIW, a side effect of it being an interpreter is that it's pretty easy to
write portable code.


> Block scope by indentation is an interesting idea, but I see one problem
> with it.  I indent Pascal according to block nesting too, but sometimes I
> cheat because otherwise the left end of the line would be too far to the
> right and there wouldn't be enough room for a meaningful comment after most
> lines.  In those cases I jump back to no indentation level and continue
> indenting from there, then jump back when the level pops back to where it
> was.  This is usually done at major breaks where there is a paragraph
> comment anyway.

I don't do that... :)  And when reviewing other's code, proper indentation
helps a lot, for me at least.

Probably this is so intriguing for me because I always use proper
indentation anyway, so the C braces or similar block markers just become
redundant. I've seen more than one bug in a C program that took longer to
find than needed due to the indentation not matching the logic, like:

 if( flag )
   dothis();
 else
   dothat();
   andalsothis();

Obviously not what's intended (or indented :), but easy to miss in a quick
glance.


> As long as there is an indentation escape mechanism, nesting by indentation
> seems like a good idea, at least without having tried it.  

I'm not aware of one, but I'm no Python wiz either.

> A deliberate indentation adjust statement would be sufficient.  Something
> like UNDENT 5 would tell the compiler that the source code will now be
> written with 5 nesting levels less although the real nesting level won't
> change.  This would be followed by INDENT 5, or maybe just INDENT, to
> restore the level.

I'd say if you need UNDENT 5, you need to restructure that thing :)

(This runs on PCs and stuff, not on PICs. So the efficiency criteria are
different.)

Gerhard

2005\02\20@113101 by Byron A Jeff

face picon face
On Sat, Feb 19, 2005 at 08:27:34PM +0100, Wouter van Ooijen wrote:
> > No reason. I took care of that by integrating a gettoken function in
> > the interpreter.
>
> Now can I write, in your language, in a single program, both the code to
> accesses the external storage device, and the code that is to be
> translated to be P-code? And what does the output look like, one hex
> file for the pic and another one for the external storage device?

I rethought what you wrote Wouter. By two hex files were you implying
that the compiler should produce P-code in one, and an augmented interpreter
in the other?

There's also a third possibly between the true compiler and true interpreter:
having the compiler produce threaded code. NPCI doesn't do that at this time,
and I have no idea where it would fall in the performance/size spectrum between
pure compiled and pure interpreted. But it would completely ditch the
fetch/decode part of the interpretation process. Of course that threaded code
would have to be integrated with the interpreter.

It's an interesting question.

BAJ

2005\02\20@115223 by olin_piclist

face picon face
Gerhard Fiedler wrote:
> I'd say if you need UNDENT 5, you need to restructure that thing :)

No, that's the point.  I don't want to artificially design my software just
so the code looks nice.  That would be the tail wagging the dog.  I want a
mechanism so that the software can be designed properly and the code can
still look nice.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\20@115923 by Sergio Masci

flavicon
face

----- Original Message -----
From: Gerhard Fiedler <listsspamBeGonespamconnectionbrazil.com>
To: Microcontroller discussion list - Public. <RemoveMEpiclist@spam@spamspamBeGonemit.edu>
Sent: Sunday, February 20, 2005 3:27 PM
Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?


> Sergio Masci wrote:
>
> >> While we're at it, and two compiler writers are discussing about useful
> >> features, John Payson came up with an interesting idea in the Htsoft forum
> >>
> >
www.htsoft.com/forum/all/showflat.php/Cat/0/Number/15352/an/0/page/0#1535
2
>
> > The only real problem that I can see with this is the relatively huge
overhead
> > of providing an interpreter. For a small device like a PIC I think that the
net
> > gain would be small and cost considerable effort.
>
> I also thought what Wouter wrote: that possibly the net gain is not that
> big, with today's good optimizing compilers. Anyway, it would be something
> for the bigger processors.

I'm sorry but I'm a bit confused. Are you saying I've missed something?

>
> The other thing Wouter wrote, about control, I think in this case the
> control would be the same a programmer has with any interpreted code. It's
> less (or it is a bit more complicated to get), but that's interpreters.

Ok, well I've definately missed the post you are refering to here. But yes I
agree, interpreters are generally not re-enterent. Interrupting one and trying
to get it to execute some other high level code can be a big problem unless the
facility is built in from the start. Even then there may be unacceptable latency
issues.

>
>
> > An alternative would be an optimising compiler that is geared towards
> > generating compact code instead of efficient code.
>
> Or where the goal can be controlled, by function (or file).

"optimise for efficiency" and "optimise for size" tend to work against each.
Allowing the user too much control over which functions are optimised in which
way would probably end up generating executables that are not optimised in
either way (result is both slow and big).

{Quote hidden}

Forget p-code. p-code is stack based and uses a dynamic runtime stack. To
generate really efficient native PIC code a compiler needs to generate code
based on a static stack. The static stack used by the compiler is at odds with
the dynamic runtime stack used by p-code. Your mixed compiler / interpreter
system would need to emulate a bigger register based processor as the kernel of
your interpreter (e.g. subset of TI9900). Your native PIC compiled code would
then be able to operate on the interpreter emulated registers as though they
were variables belonging to the app the user wrote.

e.g.
       byte    j
       int    a, b[5], c[5]

       a = b[j+1] + c[j+1]

       incf    j,w                ; native PIC code
       movwf    ireg1+1    ; access interp kernel R1
       clrf    ireg1+1

       call    interp            ; <-- enter interp mode
       mov    R0, b(R1)    ; ti9900 code
       add    R0, c(R1)
       mov    a, R0
       bl        R11            ; <-- exit interp mode

MOST importantly you should be able to enter and exit the emulated processor and
modify the emulated registers directly in native mode without needing to change
the execution context of the emulated processor (e.g. setup a stack pointer or
stack frame before entry, or clean up the stack on exit).


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use






2005\02\20@120149 by Byron A Jeff

face picon face
On Sun, Feb 20, 2005 at 03:51:39AM -0000, Sergio Masci wrote:
{Quote hidden}

That's not exactly right. The NPCI compiler only generates interpreted
bytecode. However it has a call mechanism where it can call native code
that's attached to the interpreter.

Theoretically a backend could be produced that generates threaded or
natively compiled code in addition to the bytecode. I deliberatly
separated the backend from the parser so that different code generators
could be produced.

[SNIP]

> Byron you should persevere. Knowledge and experience are good goals in their own
> right.

It's not a dead project, just dormant. There are higher priority things going
on right now, like finally finishing my dissertation.

Also NPCI isn't just a research project. It's purpose was and still is to have
a convenient language for coding up projects.

> Also here's another: PICs are cheap, you can easiliy pack several on a
> small board for very little cost, if you have a compiler that can generate code
> that can be executed from an EXTERNAL source you have the potential to build a
> system that can pass sections of code between processors. A big program with a
> pool of processors executing different parts, possibly modifying sections and
> passing them on for further processing, that's a very interesting project.

Interesting but very dangerous. Self modifying code lends itself to virtually
undebuggable errors.

Thanks for the encouragement.

BTW if anyone is interested in working on NPCI, let me know. You can find a
language overview here:

http://www.finitesite.com/d3jsys/README-NPCI.html

BAJ

2005\02\20@122940 by Sergio Masci

flavicon
face
Byron A Jeff wrote:

> Interesting but very dangerous. Self modifying code lends itself to virtually
> undebuggable errors.

I was not so much thinking of self modifying code as code containing data - the
data part being modified. Think of it more as "Remote Procedure Calls (RPC)"
where the procedure is being sent instead of just the address to the procedure.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\02\20@140750 by James Newtons Massmind

face picon face
The cost of the interpreter depends on how well the tokens are chosen. If
the tasks that the tokens complete are needed for the job at hand more often
than the set of assembly language commands available, then the cost is
minimal.

E.g. If you are going to do a job in the interpreter that is well defined
and not necessarily optimal for assembly due to its complexity, such as
processing strings or pattern analysis then the interpreter ads relatively
little overhead.

One of the best uses of an interpreter in my mind is to add slow, overall
control ability to a system that is doing fast io or other processing in
assembly. E.g. a PIC that uses the ISR to generate complex signals with a
command interpreter that allows one to set the parameters of that signal in
response to inputs. Think Basic STAMP with a better freqout command.

Another example would be an assembly FFT that finds the centerfrequncy of an
signal and then intelligently responds to it. The FFT has to run at full
speed, but the response can be much slower and can be quite complex. In this
case, a general purpose interpreter can be quite fast enough and provide
more intelligence than could be contained in assembly alone due to the
compression available with the token system.

---
James.



> {Original Message removed}

2005\02\20@141153 by James Newtons Massmind

face picon face
There is another "dead" (but not really) language called XPL-0 you might
want to look at:
http://www.piclist.com/language/xpl0

Olin might like it since it's based on Pascal. The I2L interpreter for it
could be adapted to your MicroPascal system if you ever wanted to interpret
rather than compile.

---
James.



> {Original Message removed}

2005\02\20@142156 by Wouter van Ooijen

face picon face
> Forget p-code.

In this discussion p-code is used to denote any interpreted code. The
original p-code would be a very bad choice.

Wouter van Ooijen

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


2005\02\20@142157 by Wouter van Ooijen

face picon face
> I rethought what you wrote Wouter. By two hex files were you implying
> that the compiler should produce P-code in one, and an
> augmented interpreter in the other?

I was thinking of a PIC plus an external EEPROM. PIC contains PIC code
and maybe P-code, the EEPROM can obviously contain only p-code. How
would you deliver the content of PIC and EEPROM?

{Quote hidden}

Threaded code is not a good match for the very small stack of mid-range
PICs.

Wouter van Ooijen

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


2005\02\20@142158 by Wouter van Ooijen

face picon face
> As long as there is an indentation escape mechanism,
> nesting by indentation
> seems like a good idea, at least without having tried it.  

I was very sceptic when I was introduced to this indendation (way back
at university, the language was ABC, a predecessor of Python). After
using it for a few years now I am satisfied with it, with one exception:
for debugging purposes I often want to (temporarily) disable a few
instructions. In other languages this can be done by enclosing the
statments in an if(false)..endif or something similar, but not in
Python. There is no block comment either, so you must insert an if(0):
*and* indent the range of statements. I find this the only annoying
aspect of the bloks-by-indendation mechanism. I guess a block comment
would solve it.

Olin: no, there is no escape from the indendation mechanism. If you need
as many levels as your comment seems to indicate I think you should
restructure your code. Or maybe when you convert your code to Python you
would not need that many levels because of the control structures Python
offers.

Wouter van Ooijen

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


2005\02\20@163353 by Peter L. Peres

picon face


On Sun, 20 Feb 2005, D. Jay Newman wrote:

>> if you wanted to look at that
>> look at the blackfin processors
>> $4 (1k qty) for a dual core 750 mhz cpu with DSP functions
>
> But the entire idea is to use *very* inexpensive microcontrollers.
>
> I'm thinking something cheaper. Someday. Of course, by then the
> cheap processors will be more powerful than they are today.

I don't want a 'cheap processor' and I don't want 'compatibility'. What
I'd like is a PIC style RISC cpu that has no crippling paging and
banking rules (flat code and register space), and implements traps on
illegal instructions and unimplemented data/code address access as
interrupts, perhaps in a second address space (to allow truly preemptive
multitasking). The instruction set should fit on one printed A4 page.
there should be versions from tiny (4io, all traps to one address
space) to huge (64bit direct SDRAM interface). They should all be source
level compatible and there should be a free C compiler. Only minimal
peripherals on board (interrupt on change, timer, maybe second clock and
timer for low power timekeeping). the internal flash programming
algorythm should use a self-clocked scheme using only one wire (Scenix
comes close here imho).

Peter

2005\02\20@163358 by Peter L. Peres

picon face


On Sun, 20 Feb 2005, John J. McDonough wrote:

> ----- Original Message -----
> From: "Jake Anderson" <.....grooveeeSTOPspamspam@spam@optushome.com.au>
> Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?
>
>
>> actually billing (can) work *really* well with distributed processing ;->
>
> Yeah, but I'd hate to write the COBOL compiler for a massive array of PICs.

There are papers on thread migration and pi calculus on the web. These,
and transputer technology, are the basics of distributed computing. From
what I read most everyday computing problems can be sped up a lot by
running them on a cluster but sometimes the code that decides how to
chop up the task between the cluster nodes is more complex than the task
to be solved, and it has to run on a small subset of the nodes ... so
the problem setup may take longer than solving it with a smaller
cluster. Apparently Murphy is in there somewhere *all* the time.

Peter

2005\02\20@171007 by William Chops Westfield

face picon face
On Feb 19, 2005, at 9:23 PM, D. Jay Newman wrote:

>
> But the entire idea is to use *very* inexpensive microcontrollers.
>
>
Doesn't that tend to fall apart because microcontrollers are already
so cheap that their cost is dwarfed by manufacturing issues in all but
the most mass-produced cases?

Thus the "$100 paradox" that I've mentioned a couple times.  A given
embedded computing problem costs about $100 to address, whether you
use special embedded controller board, commercial palmtop, or
last-generation PC clone.

BillW

2005\02\21@020127 by Wouter van Ooijen

face picon face
> I want a
> mechanism so that the software can be designed properly and
> the code can
> still look nice.

That argues against C or assembler, because the code will never look
nice ;)

Wouter van Ooijen

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


2005\02\21@064746 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> I rethought what you wrote Wouter. By two hex files were you implying
>> that the compiler should produce P-code in one, and an
>> augmented interpreter in the other?
>
> I was thinking of a PIC plus an external EEPROM. PIC contains PIC code
> and maybe P-code, the EEPROM can obviously contain only p-code. How
> would you deliver the content of PIC and EEPROM?

As hex files? Many programmers can program serial EEPROMs or Flash from hex
files, and if needed, some kind of bootloader could program it (as well as
the PIC).

Gerhard

2005\02\21@070810 by Gerhard Fiedler

picon face
Sergio Masci wrote:

>>> The only real problem that I can see with this is the relatively huge
>>> overhead of providing an interpreter. For a small device like a PIC I
>>> think that the net gain would be small and cost considerable effort.
>>
>> I also thought what Wouter wrote: that possibly the net gain is not that
>> big, with today's good optimizing compilers. Anyway, it would be something
>> for the bigger processors.
>
> I'm sorry but I'm a bit confused. Are you saying I've missed something?

Nope. I just wanted to express (probably did that a tad clumsily) that I
agree with you and Wouter in that the net gain possibly would be small.


>> Or where the goal can be controlled, by function (or file).
>
> "optimise for efficiency" and "optimise for size" tend to work against each.
> Allowing the user too much control over which functions are optimised in which
> way would probably end up generating executables that are not optimised in
> either way (result is both slow and big).

Hm... you're the compiler writer :)  But from a user's perspective, this
would probably be quite desirable -- if possible.


> Forget p-code. p-code is stack based and uses a dynamic runtime stack.

It's as Wouter said: I didn't really think of "real" p code. I don't know
"real" p code from the inside. I took John Payson's original idea and
purported it here, and I used his original use of p code as anything where
code is stored in some compressed form, in tokens. Maybe "token code" would
be better...

It also occurred to me, as you said, that the static call stack of PIC
compilers is a real problem for all this. It is a problem for the
interpreter, and it is a problem for calling back and forth between
interpreted and compiled code.

Gerhard

2005\02\21@071345 by Gerhard Fiedler

picon face
James Newtons Massmind wrote:

> The cost of the interpreter depends on how well the tokens are chosen. If
> the tasks that the tokens complete are needed for the job at hand more often
> than the set of assembly language commands available, then the cost is
> minimal.

> Another example would be an assembly FFT that finds the centerfrequncy of an
> signal and then intelligently responds to it. The FFT has to run at full
> speed, but the response can be much slower and can be quite complex. In this
> case, a general purpose interpreter can be quite fast enough and provide
> more intelligence than could be contained in assembly alone due to the
> compression available with the token system.

I tend to disagree. In a sense, this token interpreter is not much more
than a good, optimized library. You can use a good, optimized library in a
normal C compiler. And the glue between the calls often is quite well
optimized in the normal compilers, so that it's not really obvious whether
an interpreter would have a huge advantage here.

Are there any real-world comparisons of overall code size (including the
interpreter) between something like Basic Stamp and the same functionality
implemented in C, Jal, XCSB or whatever compiled language?

Gerhard

2005\02\21@072244 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>> I'd say if you need UNDENT 5, you need to restructure that thing :)
>
> No, that's the point.  I don't want to artificially design my software just
> so the code looks nice.  

For me, that's not about "nice", that's about ease and speed of
development, review and debugging, about maintainability, about being able
to exchange code between developers (so that others can pick up where you
left off) and so on.

But the acceptable depth of nesting, length of procedures or similar
metrics are mostly subjective criteria, of course. I'm a pretty "modular"
guy, so to speak :)

Gerhard

2005\02\21@072555 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> As long as there is an indentation escape mechanism, nesting by
>> indentation seems like a good idea, at least without having tried it.  

> After using it for a few years now I am satisfied with it, with one
> exception: for debugging purposes I often want to (temporarily) disable
> a few instructions. In other languages this can be done by enclosing the
> statments in an if(false)..endif or something similar, but not in
> Python. There is no block comment either, so you must insert an if(0):
> *and* indent the range of statements. I find this the only annoying
> aspect of the bloks-by-indendation mechanism. I guess a block comment
> would solve it.

As long as they don't add that to the language, an editor that can be made
to do that could help. There are a range of code editors that can do
something like that quite easily, just by marking the code and telling it
to comment it out.

Gerhard

2005\02\21@074615 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Wouter van Ooijen" <wouterEraseMEspam@spam@voti.nl>
Subject: RE: [EE] Languages, was Bug in Microchip mcc18 std library?


> That argues against C or assembler, because the code will never look
> nice ;)

Speak for yourself!  Beauty is in the eye of the beholder.  For the true
geeks among us, there are few things as beautiful as a well-crafted C
function.

--McD


2005\02\21@084139 by Sergio Masci

flavicon
face
John J. McDonough wrote

> > That argues against C or assembler, because the code will never look
> > nice ;)
>
> Speak for yourself!  Beauty is in the eye of the beholder.  For the true
> geeks among us, there are few things as beautiful as a well-crafted C
> function.

See what sleep deprivation does to you ;-)


Regards
Sergio Masci

2005\02\21@095341 by Sergio Masci

flavicon
face
Gerhard Fiedler wrote:


> Sergio Masci wrote:
>

> >> Or where the goal can be controlled, by function (or file).
> >
> > "optimise for efficiency" and "optimise for size" tend to work against each.
> > Allowing the user too much control over which functions are optimised in
which
> > way would probably end up generating executables that are not optimised in
> > either way (result is both slow and big).
>
> Hm... you're the compiler writer :)  But from a user's perspective, this
> would probably be quite desirable -- if possible.

Yes but a lot of work to provide a feature that most people will end up
ignoreing :-(

{Quote hidden}

Yes, p-code (or a subset of it) would lend itself to producing compact tokenised
programs but it pulls the system heavily in favour of the interpreter. The more
optimised you make the tokenised programs the harder the native compiled program
will need to work to interact with the interpreter. This translates to more
native instructions at the compiled / interpreter interface.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\02\21@095349 by Sergio Masci

flavicon
face
Gerhard Fiedler wrote:


> James Newtons Massmind wrote:
>
> > The cost of the interpreter depends on how well the tokens are chosen. If
> > the tasks that the tokens complete are needed for the job at hand more often
> > than the set of assembly language commands available, then the cost is
> > minimal.
>
> > Another example would be an assembly FFT that finds the centerfrequncy of an
> > signal and then intelligently responds to it. The FFT has to run at full
> > speed, but the response can be much slower and can be quite complex. In this
> > case, a general purpose interpreter can be quite fast enough and provide
> > more intelligence than could be contained in assembly alone due to the
> > compression available with the token system.
>
> I tend to disagree. In a sense, this token interpreter is not much more
> than a good, optimized library. You can use a good, optimized library in a
> normal C compiler. And the glue between the calls often is quite well
> optimized in the normal compilers, so that it's not really obvious whether
> an interpreter would have a huge advantage here.

I would agree with James' view IF you are adding tiny amounts of compiled native
code to a large interpreted system. However as we are discussing a compiler that
can generate mixed native compiled code and interpreted tokenised code I can see
no benefit to using a one off interpreter library function in place of a native
code library function.

As you [Gerhard] point out, "the glue between calls is often quite well
optimised". Actually this is a huge understatement. A good compiler can not only
optimise the glue to ZERO but also remove unnecessary glue present in the called
function.

Consider the function

       proc byte GET(byte *ptr)
               return *ptr
       endproc

       byte    x, y

       x = GET(&y)

The glue for this would normally look something like this

       movlw    y & 0xff
       movwf    ptr_GET_arg+0
       movlw    (y >> 8) & 0xff
       movwf    ptr_GET_arg+1

       call    SUM

       movf    result_SUM, w
       movwf    x

And the function would look like this

GET    movf    ptr_GET_arg+0,w
       movwf    FSR
       bcf    STATUS, IRP
       btfsc    ptr_GET_arg+1, 0
       bsf    STATUS, IRP

       movf    INDF, w
       movwf    result_SUM
       return

Now a good optimising compiler could actually produce something like this

       call    GET        ; the only instruction in the glue

And the function

GET    movf    y, w        ; NOTE removed glue here
       movwf    x
       return

This level of optimisation would not be possible in an interpreted library
function.

>
> Are there any real-world comparisons of overall code size (including the
> interpreter) between something like Basic Stamp and the same functionality
> implemented in C, Jal, XCSB or whatever compiled language?

I do not have any for XCSB and I do not know of any for JAL or C. But I would be
very surprised if the BS came anywhere close.


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimised PIC compiler
FREE for personal non-commercial use





2005\02\21@103251 by Wouter van Ooijen

face picon face
> There are a range of code editors that can do
> something like that quite easily, just by marking the code
> and telling it
> to comment it out.

Yeah, but I don't like relying on yet another editor, that is probably
available on only half the platforms I use, and on that half I often
have to use a machine that is configuared not to allow me to install
anything.

Wouter van Ooijen

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


2005\02\21@103251 by Wouter van Ooijen

face picon face
> > That argues against C or assembler, because the code will never look
> > nice ;)
>
> Speak for yourself!  Beauty is in the eye of the beholder.  
> For the true
> geeks among us, there are few things as beautiful as a well-crafted C
> function.

I guess you forgot to include the smiley?

Wouter van Ooijen

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



2005\02\21@110208 by Walter Banks

picon face
In the studies we did Basic Stamp was still larger than compiled C for any application that fit
inside a PIC's memory space when you included the interpreter for the same application.
The Basic stamp's one significant advantage was the ability to have external storage for
the application. The intermediate code in the stamp is about as tight as any of the
Interpreted code that we studied.

w..


Gerhard Fiedler wrote:

> Are there any real-world comparisons of overall code size (including the
> interpreter) between something like Basic Stamp and the same functionality
> implemented in C, Jal, XCSB or whatever compiled language?


2005\02\21@112123 by Walter Banks

picon face
Some of the more common appliance problems split very nicely into parts.  One Micro ware
oven I am familiar with was prototyped with a single processors and then split into
three parts keypad, display and oven controller. The code in this case was hand split on
geographical centers of reference (keypad was connected to keypad processor) same
with display and oven and then recreated for three processors. The port took a few days
and reduced the production cost. The inter-processor communication was bit serial.


w..


"D. Jay Newman" wrote:

> I agree. However, there are some problems that can be broken up
> along simple lines (such as those solvable by array processors).
>
> I never said that I wanted to make a general purpose processor.
> --


2005\02\21@115724 by Byron A Jeff

face picon face
On Mon, Feb 21, 2005 at 09:08:01AM -0300, Gerhard Fiedler wrote:
> > Forget p-code. p-code is stack based and uses a dynamic runtime stack.
>
> It's as Wouter said: I didn't really think of "real" p code. I don't know
> "real" p code from the inside. I took John Payson's original idea and
> purported it here, and I used his original use of p code as anything where
> code is stored in some compressed form, in tokens. Maybe "token code" would
> be better...

bytecode is another term that is typically used too.

BAJ
>

> It also occurred to me, as you said, that the static call stack of PIC
> compilers is a real problem for all this. It is a problem for the
> interpreter, and it is a problem for calling back and forth between
> interpreted and compiled code.

It's a problem that is solved with a software stack. That's what the NPCI
bytecode interpreter implements.

BAJ

2005\02\21@120943 by Harold Hallikainen

face picon face
I did something similar where a couple switches and a 2 digit display
could not be put on the same board as the controller (they were not in the
same plane). So, I put another PIC on a second board to drive the displays
and read the switches. It communicated with the main board using polled
packet communications on an open collector type bus driven by the pic
uarts on each end of the inch or so of wire between the two. The transmit
side of the uarts went though a diode so they could pull the data line
down, but not up. A single pull-up resistor pulled the line up.

Harold


{Quote hidden}

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

2005\02\21@163759 by James Newtons Massmind

face picon face
You and Sergio are probably right in that a good compiler can make more
efficient the library of routines that would be used in a interpreted
language for the case you quoted.

I may have been influenced by past experiences where I ran out of room in
the chip and actually moved the tokens off chip in external EEPROM, etc...

There is, however, another case where the interpreted language is really
necessary: When you need to change the program without re-programming the
chip. E.g. when the language is really the control commands for the
functions the system carries out, or when you want to sell something that
can be "programmed" by the end user without re-programming the PIC.

The Stamp is the obvious example, but PLCs, co-processors and other such
things are also in that class.

And, just to get really weird, if you think about it, a PIC responding to a
complex collection of inputs from sensors, etc. is actually "interpreting"
the "program" written by those inputs. The same pattern recognition, token
interpreting tools that are used to make a thing like the stamp can be used
to make other, responsive, systems.

For a good example, see:
http://www.piclist.com/techref/new/letter/news0303.htm and scroll down to
the "Keyless Matrix Wired-Pen Data Entry Pad." Notice that the Keywork
Interpreter code generator
http://www.piclist.com/codegen/keyword_interpreter.htm is used to recognize
the letter being drawn on the "pad."

---
James.



> {Original Message removed}

2005\02\21@194632 by Sergio Masci

flavicon
face
Byron A Jeff wrote:

>
> > It also occurred to me, as you said, that the static call stack of PIC
> > compilers is a real problem for all this. It is a problem for the
> > interpreter, and it is a problem for calling back and forth between
> > interpreted and compiled code.
>
> It's a problem that is solved with a software stack. That's what the NPCI
> bytecode interpreter implements.
>
> BAJ

I have obviously not been clear. The software stack is what is causeing concern.
One uses this stack to hold values that are being acted on. One then refers to
these values either implicitly (always top of stack, top of stack -1 etc) in
specific operations or relative to the top of stack. Finding the TOS at runtime
imposes a performance and code space penalty when moving values to or from the
stack from a compiled native code fragment.

e.g. (1)

;;; dynamic stack based parameter passing
;;; push(a)

       bsf    STATUS, IRP
       decf    TOS, w
       movwf    FSR
       movf    a+1, w
       movwf    INDF
       decf    FSR
       movf    a+0, w
       movwf    INDF
       movf    FSR, w
       movwf    TOS

e.g. (2)

;;; static stack based parameter passing
;;; push(a)

       movf    a+0, w
       movwf    R0+0
       movf    a+1, w
       movwf    R0+1

In e.g.(1) the interpreter performs operations relative to the TOS variable so
the compiler cannot access RAM belonging to the interpreter directly. In e.g.(2)
the interpreter TOS is mapped to emulated registers R0, R1, R2 etc and the TOS
is computed statically at compile time.

Furthermore using R0, R1, R2 etc allows the compiler to optimise expression
evaluation so that a result can be built directly in an emulated register
instead of a temporary RAM location which subsequently needs to be copied to the
TOS.

e.g. (3)
;;; push(a+b)

       movf    a+1, w
       movwf    R0+1

       movf    a+0, w
       addwf    b+0, w
       movwf    R0+0

       btfsc    STATUC, C
       incf    R0+1

       movf    b+1, w
       addwf    R0+1

I am not saying a software stack is bad, just that mixing a static stack and a
dynamic stack causes optimisation problems.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\02\21@202205 by William Chops Westfield

face picon face
On Feb 21, 2005, at 4:51 PM, Sergio Masci wrote:

> The software stack is what is causeing concern.
>
Thus the interest in threaded code, I think.  If I understand it,
the idea is to remove the usual overhead of function calls by
creating a highly standardized mechanism for passing parameters
around and back, so that your code becomes simply:
       call foo
       call bar
       call baz
       call print
trivial to turn into "interpreted" code with little additional
performance loss by omitting the 'call' part and turning the
targets into tokens.

But the overhead of an interpreter written to implement that
is moderately large, unless the foo/bar/baz/etc functions are
pretty complex compared to assembler code.

hmm.  Postscript is probably a very good example of a language
that utilizes very complex "primitives" for an interpreter to
good value.  For a PIC, any code that makes extensive use of
floating point or fractional math might benefit...

BillW

2005\02\21@211113 by Sergio Masci

flavicon
face
William Chops Westfield wrote:

> On Feb 21, 2005, at 4:51 PM, Sergio Masci wrote:
>
> > The software stack is what is causeing concern.
> >
> Thus the interest in threaded code, I think.  If I understand it,
> the idea is to remove the usual overhead of function calls by
> creating a highly standardized mechanism for passing parameters
> around and back, so that your code becomes simply:
> call foo
> call bar
> call baz
> call print
> trivial to turn into "interpreted" code with little additional
> performance loss by omitting the 'call' part and turning the
> targets into tokens.

Yes. In fact I suggested using calls instead of tokens (eariler in this thread)
where native machine code is to be mixed with interpreted code (I wasn't
considering external program storage at the time).

A "software stack" is a very efficient way of generating your highly
standardised parameter passing mechanism. BUT only for interpreted code. Yes I
do like the stack honest :-) It will be much slower than a non-stack alternative
but what you lose in speed you gain in simplicity and compatness.

The problem is that if people want a compiler that generates highly efficient
native machine code AND highly compact interpreted code then the software stack
is an incredible handycap.

>
> But the overhead of an interpreter written to implement that
> is moderately large, unless the foo/bar/baz/etc functions are
> pretty complex compared to assembler code.
>
> hmm.  Postscript is probably a very good example of a language
> that utilizes very complex "primitives" for an interpreter to
> good value.  For a PIC, any code that makes extensive use of
> floating point or fractional math might benefit...

Please don't get me started on PS :-)

As I said earlier, it is possible to produce a compiler that optimises for space
instead of speed if space is the issue. This would greatly reduce the overheads
for floating point, large integer and fixed point calculations. With this in
mind I belive you would need a very large external tokenised program to justify
an interpreter. Ok so we increase the effective code size to 128K what do we do
about the puny 368 bytes of RAM? My experience is that larger programs tend to
need more variable space than smaller programs.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use






2005\02\22@075021 by olin_piclist

face picon face
Sergio Masci wrote:
> In e.g.(2) the interpreter TOS is mapped to emulated
> registers R0, R1, R2 etc and the TOS is computed statically at compile
> time.

So how is that a "stack" at all?  It sounds more like a statically allocated
communications buffer.

By the way, there are other ways to handle call parameters and local
variables than the two methods you outlined.  I use fixed global variables
like general registers of other machines.  These go in the limited space at
offset 70h to 7Fh that is mapped to the same storage in all banks.  These
general registers are used for parameter passing, and are otherwise
preserved by subroutines.  To accomplish this, a subroutine pushes registers
that it will trash but not return values in onto a software stack, then pops
them before returning.  This is particularly easy on the PIC 18 because I
reserve FSR2 as the software stack pointer.  A register can be pushed or
popped with a single instruction.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\02\22@090705 by Sergio Masci

flavicon
face
Olin Lathrop wrote:

> Sergio Masci wrote:
> > In e.g.(2) the interpreter TOS is mapped to emulated
> > registers R0, R1, R2 etc and the TOS is computed statically at compile
> > time.
>
> So how is that a "stack" at all?  It sounds more like a statically allocated
> communications buffer.

>From the native machine code compiled side it does behave EXACTLY like a
statically allocated comminucations buffer. This greatly reduces access overhead
on the native side which is very important if the overall goal is to increase
code desity. It is a stack on the interpreter side because the interpreter's
PUSH and POP functions actually map these registers to the top of stack (TOS)

e.g.
       proc PUSH(int arg)
               tos = tos - 1
               interp_stack[tos] = R3
               R3 = R2
               R2 = R1
               R1 = R0
               R0 = arg
       endproc

       proc POP()
               R0 = R1
               R1 = R2
               R2 = R3
               R3 = interp_stack[tos]
               tos = tos + 1
       endproc

Now PUSH and POP seem really inefficient but that is not the issue, code density
is. Also there is a non-obvious benefit to mapping the TOS to emulated
registers: the data held in the TOS can be accessed more efficiently by the
interpreter since it does not need to use an index register

e.g.
       interpreter ADD which would normally be written as:

       proc ADD()
               interp_stack[tos-1] = interp_stack[tos-1] + interp_stack[tos]
               tos = tos - 1
       endproc

       becomes

       proc ADD()
               R1 = R1 + R0
               POP()
       endproc

{Quote hidden}

In a previous posting I mentioned using an emulated TI9900 (actually a subset of
one). This would be almost exactly what you are proposing here. Moveing away
from this towards a more high level interpreter was purely a mater of exploring
options and possible solutions.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use






2005\02\22@111213 by ThePicMan

flavicon
face
At 10.57 2005.02.21 -0500, you wrote:
>In the studies we did Basic Stamp was still larger than compiled C for any
>application that fit
>inside a PIC's memory space when you included the interpreter for the same
>application.
>The Basic stamp's one significant advantage was the ability to have external
>storage for
>the application. The intermediate code in the stamp is about as tight as any
>of the
>Interpreted code that we studied.

Let's not forget that PICs like the PIC18F8720 can execute code from external
memory too..

Greets,
TPM

2005\02\24@110001 by ThePicMan

flavicon
face
At 16.15 2005.02.20 +1100, you wrote:
>
>if you wanted to look at that
>look at the blackfin processors
>$4 (1k qty) for a dual core 750 mhz cpu with DSP functions

THAT one, the ADSP-BF561SKB750, costs $85.72 per 10K units..

2005\02\24@124330 by Wouter van Ooijen

face picon face
> THAT one, the ADSP-BF561SKB750, costs $85.72 per 10K units..

:( :(

I can live with $10 .. $20 for 1k, above that the chip must be *realy
realy* interesting!
Wouter van Ooijen

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


2005\02\24@151357 by steve

flavicon
face


On 24 Feb 2005 at 18:43, Wouter van Ooijen wrote:

> > THAT one, the ADSP-BF561SKB750, costs $85.72 per 10K units..
>
> :( :(
>
> I can live with $10 .. $20 for 1k, above that the chip must be *realy
> realy* interesting! Wouter van Ooijen

$85.72 for 10k units. That's less than 9 cents each. That _is_
interesting.
:-)

Steve.




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