Searching \ for '%STD%' 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/index.htm?key=std
Search entire site for: 'STD'.

_Sub string match.
PICList Thread
'[OT] PicListDigest 30 Aprl to 1 May'
2000\05\02@120141 by Christoph Klein

flavicon
face
Hi Piclisters!

Anybody still in possession of the above digest and willing to sent
it to me? Please give me a note: spam_OUThylaTakeThisOuTspammayn.de

Thank You!

Christoph


'[PIC]: Nikolai constdivmul generator'
2001\02\16@061000 by Vasile Surducan
flavicon
face
There is an executable for this instead of online basic one ?
You may crying at slow connection...
Vasile

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads



'[PIC]: What happens if MOVFF POSTINC0,POSTDEC0 is '
2001\04\19@074805 by Bob Ammerman
picon face
I haven't tried this, but here is my guess based on my understanding of the
way the 18C handles MOVFF instructions.

In terms of execution cycles, I am pretty sure the 18C basically treats:

   MOVFF a,b

as if it were:

   MOVF   a,Z
   MOVZF b

where 'Z' is an 'invisible' register similar to W.

If I am right then your:

   MOVFF   POSTINC0,POSTDEC0

becomes

   MOVF    POSTINC0,Z
   MOVZF  POSTDEC0

etc.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)



{Original Message removed}

2001\04\19@113103 by David P. Harris

picon face
Hi-
I have not these either, but my guess is:
 MOVFF POSTINC0, POSTDEC0
means that the first pointer is incremented after the move, and the
second pointer is decremented before the move.  The pointers are table
registers which are designed to step through tables.
(reminds me of PDP11 mov (a)+, -(b))
David

K|bek Tony wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\04\23@073533 by Kari Lehikko
flavicon
face
Well... What about movf POSTINC0,f ? :)

I haven't got the nerve to use that one :P

- Kari -

Kübek Tony wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\04\23@130405 by Bob Ammerman

picon face
> Well... What about movf POSTINC0,f ? :)

This (and others like it are), I am almost certain, well defined.

The read and write will both occur to the initial address in FSR, then FSR
will be adjusted.

For PREINC0,f the read and write will both occur to the incremented address.

This is because effective address compution is done only once per
instruction, unless I am very much mistaken.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics



'[PICLIST] [ADMIN]:Problem reading PICLISTDigest'
2001\07\13@205415 by Eric Strauts
flavicon
face
--Message-Boundary-10219
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

I am surprised there are so few complaints about the changes that
occured to the PICLIST Digest around May 26th.

At that time blank lines after the first message were replaced with
a single space and then the CR-LF characters to move to the next
line. I use Pegasus Mail and it responded to this change by only
showing a single message and ignoring the rest. This is consistent
with what several others have reported.

I wrote a script file for Winedit (http://www.winedit.com) that removes the
extra spaces and makes everything visible and viewable again. It is
attached to this post. I use Winedit 2000 build 2000b. I assume it
will also work with newer versions. The only change you will need
is to change the first line which calls out the directory in which the
email files are located.

I usually run it and sort the files in the list box by date and select
the most recent to process the latest digest file. Running the script
again on an already "fixed" file doesen's hurt anything.

If anyone wants to do this another way just search for the hex
pattern "0D 0A 20 0D 0A" and replace it with "0D 0A 0D 0A".

I will also send this message in private email to several PIClisters
that said they could not "see" the digest anymore.



--Message-Boundary-10219
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Text from file 'PIClist convert.wbt'

file=AskFileName("SelectFile", "C:\pmail\mail\", "Mime Files|*.cnm", "", 1)
fs=FileSize(file)
binbuf = BinaryAlloc(fs)
binbuf2 = BinaryAlloc(fs)
BinaryRead(binbuf, file)
endfile = BinaryEodGet( binbuf )
b= BinaryStrCnt( binbuf, 0,endfile-1, "%@CRLF% %@CRLF%")
start=0
finish=0
while finish != -1
       finish = BinaryIndexEx( binbuf, finish+3, "%@CRLF% %@CRLF%", @FWDSCAN,1 )
       if finish != -1
               endfile2 = BinaryEodGet( binbuf2 )
               BinaryCopy(binbuf2,endfile2,binbuf,start,finish+2-start)
               start=finish+3
       else
               endfile2 = BinaryEodGet( binbuf2 )
               BinaryCopy(binbuf2,endfile2,binbuf, start,endfile-start)
       endif
endwhile
BinaryWrite(binbuf2, file)
BinaryFree(binbuf)
BinaryFree(binbuf2)
Message( "Results", "Total invalid chars %b%" )
Exit


--Message-Boundary-10219--

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.



'[PIC]: MIL-STD-1553'
2002\12\05@181646 by Mark Samuels
flavicon
face
Anyone ever interfaced a PIC (or any other 8-bit micro) to a MIL-STD-1553 bus?


-------------------------------------------
Mark Samuels
ARMA Design
Tel:(858) 373-1320
Fax:(858) 373-1325
Email: .....markKILLspamspam.....armanet.com
Web: http://www.armanet.com



The information contained in this electronic message is private and may
contain privileged, confidential or inside information.  Any distribution,
copying or forwarding or use of this communication by anyone other than the
intended recipient(s) is strictly prohibited and may be unlawful.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\12\06@140150 by Wouter van Ooijen

face picon face
> Anyone ever interfaced a PIC (or any other 8-bit micro) to a
> MIL-STD-1553 bus?

No, but I do have experience with both. What do you want, interfacing
directly (using only an electrical interface) or using one of the
'standard' hybrids? Unless you are forced to use 1553 (military,
avionics, space) I would rather avoid it, the hardware is very
expensive.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\12\06@145806 by Mark Samuels

flavicon
face
Because it is a military application, cost really isn't an issue, so I have
been looking at using one of the hybrid physical/protocol interfaces,
particularly DDC's "MINI-ACE", which requires only the transformers as
external components.  The part is the smallest I've seen so far (of course,
the whole project has an impossibly small size constraint), but is meant to
connect to something with gobs of available I/O.  There is an 8-bit mode
which will cut the interface down to "only" 21 lines, but I just wanted to
see if there were any other physically small alternatives.

-Mark

At 08:01 PM 12/6/02 +0100, you wrote:
{Quote hidden}

-------------------------------------------
Mark Samuels
ARMA Design
Tel:(858) 373-1320
Fax:(858) 373-1325
Email: markspamspam_OUTarmanet.com
Web: http://www.armanet.com



The information contained in this electronic message is private and may
contain privileged, confidential or inside information.  Any distribution,
copying or forwarding or use of this communication by anyone other than the
intended recipient(s) is strictly prohibited and may be unlawful.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\12\06@160309 by Wouter van Ooijen

face picon face
AFAIK nearly everyone uses one of the ACE hybrids, you would have a hard
time implementing the protocol if that is what you want the PIC for.
Indeed, the hybrids are better suited to a uC with some RAM than to a
uC.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products


> {Original Message removed}


'[EE]: std PWM vs motor control PWM?'
2004\03\09@082253 by Omega Software
flavicon
face
Hi,

after reading www.microchip.com/download/lit/pline/dspic/progman/70062b.pdf
it's still not clear to me.

What's the difference between "standard PWM" and "motor control PWM"? I mean, does
the latter gives any important advantage for PWM applications in general (motor
related or *not*)?

On a side note, how can I obtain some pre-production dsPIC devices?

Thanks,
Andrea

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\03\09@102608 by Spehro Pefhany

picon face
At 02:17 PM 3/9/2004 +0100, you wrote:
>Hi,
>
>after reading
>www.microchip.com/download/lit/pline/dspic/progman/70062b.pdf
>it's still not clear to me.
>
>What's the difference between "standard PWM" and "motor control PWM"? I
>mean, does
>the latter gives any important advantage for PWM applications in general
>(motor
>related or *not*)?

Could be of advantage whenever you are driving a power push-pull output
such as an H-bridge or half-bridge. For example, to drive a high-frequency
power transformer.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
KILLspamspeffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\03\09@154345 by steve

flavicon
face
> What's the difference between "standard PWM" and "motor control
PWM"?
> I mean, does the latter gives any important advantage for PWM
> applications in general (motor related or *not*)?

If you were to look at a single PWM pin on a scope, there would be little
difference. What makes this module more than a standard (PIC16 style)
PWM is the complementary outputs with deadband and that there are
multiple PWM's working from a common timer and as a unified system.

The complementary outputs allow you to drive a half bridge and the
deadband prevents current flowing through both power devices at the same
time. Since the deadband can be controlled by software, that saves using
external components to do the same thing.

Having multiple PWM's connected together allows you to generate 3 sine
waves (for example), all at the same frequency but at different phases. This
is exactly what is needed for certain types of motor control. They have also
catered for faults, again saving external hardware.

Steve.

==========================================
Steve Baldwin                          Electronic Product Design
TLA Microsystems Ltd             Microcontroller Specialists
PO Box 15-680, New Lynn                http://www.tla.co.nz
Auckland, New Zealand                     ph  +64 9 820-2221
email: RemoveMEsteveTakeThisOuTspamtla.co.nz                      fax +64 9 820-1929
=========================================

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


'[PIC] Bug in Microchip mcc18 std library?'
2005\02\14@170646 by Hulatt, Jon
picon face
Hi All,

I've observed this evening that the implementation of putrsUSART in the
std libs is somewhat odd.

putrsUSART sends a string from rom to the USART.  it's defined as:-

void putrsUSART(const rom char *data);

It's my understanding that C, and C++ for that matter, represent strings
as null terminated arrays of char. And, logically, the string does not
include the null terminator. So, the implementation of putrsUSART should
not include the terminating null.

Here is the definition of the function:-

void putrsUSART(const rom char *data)
{
 do
 {  // Transmit a byte
   while(BusyUSART());
   putcUSART(*data);
 } while( *data++ );
}

The effect of this definition is that, for example, calling
putrsUSART("Hello"); outputs 6 chars - the 5 of Hello, and then a
terminating null.

It happens because the while loop control statement is a postfix
increment, rather than a prefix increment. This also leads to a side
effect of poor handling of null strings- IMO putrsUSART(""); should do
precisely nothing- in this implementation it will output a null.

So, if i'm right in thinking that this function should not include the
terminating null charactor in it's output, then this is a bug. Do you
agree with me? and is there a microchip bug reporting thing out there
anywhere?

IMHO a better implementation would be:-

void putrsUSART(const rom char *data)
{
 while( *data++ );
 {  // Transmit a byte
   while(BusyUSART());
   putcUSART(*data);
 }
}

ie. The condition is evaluated ahead of time.

Do you agree that this is a bug?

(Yes, I've already recompiled my std libraries, but I don't feel
comfortable with using non-standard, standard libs.)

Jon

2005\02\14@171409 by Robin Abbott

flavicon
face
A quick rat hole - does C18 not allow any pointer to freely point to ROM
and RAM ? Would explain some strange constructs in the C18 program that
I have been converting !

Robin Abbott

Forest Electronic Developments

01590 681511
+44 1590 681511 (phone/fax)

See our web pages : http://www.fored.co.uk



{Original Message removed}

2005\02\14@174959 by olin_piclist

face picon face
Hulatt, Jon wrote:
> void putrsUSART(const rom char *data)
> {
>   do
>   {  // Transmit a byte
>     while(BusyUSART());
>     putcUSART(*data);
>   } while( *data++ );
> }

This is a bug if for no other reason than it always emits at least one byte.
I also don't like the busy wait.

<soapbox>Stuff like *DATA++ reminds me of why C is so evil in the first
place.  It's bad enough that the language allows you to put three separate
things into one statement, but even worse when someone writes code like
that.  No optimizations would have been lost by writing this as two lines:

 data++;           //advance to next character in string
 } while (*data);  //back to handle next character

C has encouraged a whole generation of programmers to write cutesy obtuse
code.</soapbox>


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

2005\02\14@191030 by piclist

flavicon
face
On Mon, 14 Feb 2005, Robin Abbott wrote:

> does C18 not allow any pointer to freely point to ROM and RAM ?

It does not.

--
John W. Temples, III

2005\02\14@191651 by Lee Jones

flavicon
face
{Quote hidden}

By convention, a pointer to a string is aimed at the first char
in the array.  Using a pre-increment would ignore the first char.

> This also leads to a side effect of poor handling of null strings-
> IMO putrsUSART(""); should do precisely nothing

Agreed.

> So, if i'm right in thinking that this function should not include
> the terminating null charactor in it's output, then this is a bug.
> Do you agree with me?

Yes.

{Quote hidden}

I've never used MCC18, but I have used C for decades.  Possibly
MCC18 has a non-ANSI implementation of use of semi-colons after
loop constructs, such as while.  My following analysis assumes
that the rules of ANSI C hold true.

The while() construct executes a single statement while the
condition is true.  The statement can either be a simple statement
or a compound statement.

Your inclusion of a semi-colon at the end of the first while()
causes that while to loop until the terminating null has been
reached.  It leaves the pointer aimed at the first char after
that null.  The compound statement following it will wait for the
USART to be non-busy then emit a single char -- the char following
the first string's terminating null.

I think it should be written as follows:

void putrsUSART(const rom char *data)
{
   while( *data )                        /* repeat until terminating null */
   {
       while( BusyUSART() )                /* spin wait (BAD IDEA) until ready */
           ;
       putcUSART(*data);                /* load one char into USART */
   }
   return;
} /* putrsUSART() */

Note the simple statement of the second while() loop is set off
on a seperate line so that it is obvious.  Just because C allows
poor human engineering doesn't mean you can't use indentation and
white space to make your design clearer & more obvious.

And, yes, I know I don't _need_ the return; statement but I like
to be obvious when I revisit the routine (months or years later).

The use of a spin wait in a routine that may wait for more than
30 milliseconds (i.e. 1 char time at 300 baud) is not a good idea
if the PIC has any other tasks to complete.

                                               Lee Jones


2005\02\14@191744 by Andrew Warren

flavicon
face
Olin Lathrop <spamBeGonepiclistspamBeGonespammit.edu> wrote:

> > } while( *data++ );
> ....
> Stuff like *DATA++ reminds me of why C is so evil in the first
> place.  It's bad enough that the language allows you to put three
> separate things into one statement, but even worse when someone
> writes code like that.  No optimizations would have been lost by
> writing this as two lines:
>
> data++;           //advance to next character in string
> } while (*data);  //back to handle next character

Olin:

As you become more familiar with C, idioms such as "while(*p++)" will
eventually seem no more complicated to you than "decfsz count", which
also puts at least three things into one statement...  

There's lots of bad C code in the world, but that one line isn't an
example of it.

-Andy

P.S. By the way, your code isn't equivalent to the original.

=== Andrew Warren -- TakeThisOuTaiwEraseMEspamspam_OUTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
=== (but open to offers)
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

2005\02\14@191934 by Lee Jones

flavicon
face
>From lee Mon Feb 14 16:23:35 2005
To: RemoveMEpiclistspamTakeThisOuTmit.edu
Subject: Re:  [PIC] Bug in Microchip mcc18 std library?
Status: R

Oops, as soon as I sent my last message I realized I had
forgotten to add a crucial line to the revised funciton.


{Quote hidden}

By convention, a pointer to a string is aimed at the first char
in the array.  Using a pre-increment would ignore the first char.

> This also leads to a side effect of poor handling of null strings-
> IMO putrsUSART(""); should do precisely nothing

Agreed.

> So, if i'm right in thinking that this function should not include
> the terminating null charactor in it's output, then this is a bug.
> Do you agree with me?

Yes.

{Quote hidden}

I've never used MCC18, but I have used C for decades.  Possibly
MCC18 has a non-ANSI implementation of use of semi-colons after
loop constructs, such as while.  My following analysis assumes
that the rules of ANSI C hold true.

The while() construct executes a single statement while the
condition is true.  The statement can either be a simple statement
or a compound statement.

Your inclusion of a semi-colon at the end of the first while()
causes that while to loop until the terminating null has been
reached.  It leaves the pointer aimed at the first char after
that null.  The compound statement following it will wait for the
USART to be non-busy then emit a single char -- the char following
the first string's terminating null.

I think it should be written as follows:

void putrsUSART(const rom char *data)
{
   while( *data )                        /* repeat until terminating null */
   {
       while( BusyUSART() )                /* spin wait (BAD IDEA) until ready */
           ;
       putcUSART(*data);                /* load one char into USART */
       data++;                                /* move on to next char */
   }
   return;
} /* putrsUSART() */

Note the simple statement of the second while() loop is set off
on a seperate line so that it is obvious.  Just because C allows
poor human engineering doesn't mean you can't use indentation and
white space to make your design clearer & more obvious.

And, yes, I know I don't _need_ the return; statement but I like
to be obvious when I revisit the routine (months or years later).

The use of a spin wait in a routine that may wait for more than
30 milliseconds (i.e. 1 char time at 300 baud) is not a good idea
if the PIC has any other tasks to complete.

                                               Lee Jones



2005\02\14@192013 by piclist

flavicon
face
On Mon, 14 Feb 2005, Hulatt, Jon wrote:

> So, the implementation of putrsUSART should
> not include the terminating null.

> Do you agree that this is a bug?

A misfeature, perhaps, but not a bug.  The manual documents the
behavior you describe.

--
John W. Temples, III

2005\02\14@194105 by piclist

flavicon
face
On Mon, 14 Feb 2005, Olin Lathrop wrote:

> This is a bug if for no other reason than it always emits at least one byte.

Not if that's what it's documented to do.

> <soapbox>Stuff like *DATA++ reminds me of why C is so evil in the first
> place.  It's bad enough that the language allows you to put three separate
> things into one statement, but even worse when someone writes code like
> that.  No optimizations would have been lost by writing this as two lines:
>
>  data++;           //advance to next character in string
>  } while (*data);  //back to handle next character

*ptr++ is a very common C construct.  I would imagine most experienced
C programmers would find your version less readable, not more.

--
John W. Temples, III

2005\02\14@201409 by John J. McDonough

flavicon
face
----- Original Message -----
From: <piclistEraseMEspam.....xargs.com>
Subject: Re: [PIC] Bug in Microchip mcc18 std library?


> *ptr++ is a very common C construct.  I would imagine most experienced
> C programmers would find your version less readable, not more.

common is an understatement.  OK, maybe 90% of the time it seems like it is
the ubiquitous 'p', so while *ptr++ might not be that common, *p++ is
everywhere!

Telling a C programmer to write
  data++;
 } while (*data);

Is like telling a BASIC or FORTRAN programmer that I=I+1 is too confusing
and somehow the code would be more clear if he wrote
   K=I
   I=K+1
yeah, right.

--McD


2005\02\14@213103 by Bob Ammerman

picon face
> I think it should be written as follows:
>
> void putrsUSART(const rom char *data)
> {
>    while( *data ) /* repeat until terminating null */
>    {
> while( BusyUSART() ) /* spin wait (BAD IDEA) until ready */
>     ;
> putcUSART(*data); /* load one char into USART */
>    }
>    return;
> } /* putrsUSART() */
>

Unfortunately, this is still broken. How about:


void putrsUSART(const rom char *data)
{
   while( *data ) /* repeat until terminating null */
   {
       while( BusyUSART() )
            /*spin wait for UART*/ ;
      putcUSART(*data); /* load one char into USART */
      +data;
   }
   return;
} /* putrsUSART() */

Bob Ammerman
RAm Systems


2005\02\15@032132 by ThePicMan

flavicon
face

Olin Lathrop wrote:

><soapbox>Stuff like *DATA++ reminds me of why C is so evil in the first
>place.  It's bad enough that the language allows you to put three separate
>things into one statement, but even worse when someone writes code like
>that.  No optimizations would have been lost by writing this as two lines:
>
>  data++;           //advance to next character in string
>  } while (*data);  //back to handle next character
>
>C has encouraged a whole generation of programmers to write cutesy obtuse
>code.</soapbox>

Great power requires great responsability..
C was made for Real Programmers (tm), others have options like BASIC. *grin*

2005\02\15@032357 by Wouter van Ooijen

face picon face
> C has encouraged a whole generation of programmers to write
> cutesy obtuse code.

Nobody denies that! But at least they write somewhat *portable* cutesy
obtuse (that's beyond my knowledge of english, but I can guess) code. C
is often reffered to as 'the best assembler around', so you of all
people should love it ;) (and the object code generated by a C compiler
is in relocateable format!)

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\15@032357 by Wouter van Ooijen

face picon face
> I've observed this evening that the implementation of
> putrsUSART in the std libs is somewhat odd.

I mostly avoid using the uChip libraries. I never got the LCD lib to
work, so I wrote my own. There was some trouble with the UART lib too,
so again I wrote my own (it is not that hard to do).

So don't feel guilty about changing the lib, although you should now
regard it as 'your' lib, not a standard lib.

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\15@032357 by Wouter van Ooijen

face picon face
> A quick rat hole - does C18 not allow any pointer to freely
> point to ROM
> and RAM ? Would explain some strange constructs in the C18
> program that
> I have been converting !

AFAIK is does not.

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\15@035219 by Hulatt, Jon

picon face
lol.


>Your inclusion of a semi-colon at the end of the first while() causes
that while to loop until the terminating null has been >reached.  It
leaves the pointer aimed at the first char after that null.  The
compound statement following it will wait for >the USART to be non-busy
then emit a single char -- the char following the first string's
terminating null.

My inclusion of a semi-colon was a typo ;-)

However, even without it, my code doesn't work right.

while( *data++ )
{  
  // Transmit a byte
  while(BusyUSART());
  putcUSART(*data);
}

What the Microchip compiler is doing for that is basically while
(*(data++)) , so the first char is always missed. My bad. Or is it? I'm
going to check the text books today to see what the ANSI operator
precedence should be. I thought that would work.

Jon

{Original Message removed}

2005\02\15@035530 by Hulatt, Jon

picon face


>The use of a spin wait in a routine that may wait for more than 30
milliseconds (i.e. 1 char time at 300 baud) is not a good >idea if the
PIC has any other tasks to complete.

makes me very very glad Microchip include the library source code and a
way of recompiling. At least we can see that that is what it does.





2005\02\15@043542 by Ake Hedman

flavicon
face
John J. McDonough wrote:

{Quote hidden}

Who really cares... An experienced programmer will have no problem with either form. The
...
} while (*p++);
form will probably be the most common  but I can't see why anyone of them should be easier  to read.

Cheers
/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

2005\02\15@044236 by Hulatt, Jon

picon face
That's pretty much what i've now decided to do.

I did previously get the LCD lib working (with an lcd you supplied me,
no less!), but to have to recompile the libraries to match the pin/port
configuration you're using seems a bit c**p to me.



{Original Message removed}

2005\02\15@052230 by Jan-Erik Soderholm

face picon face
Hulatt, Jon wrote :

> I did previously get the LCD lib working, but to have to
> recompile the libraries to match  the pin/port
> configuration you're using seems a bit c**p to me.

Right, that's the major problem with obj libraries.
And also why many uses source code "libraies" (usualy as
include files) so you can use compile/assembly time calculations
and conditional builds on the fly. Changing pins for the LCD
whould in that case need no changes to the include file (if
written properly) just setting up some symbols i the main code.

A "LCD library" with *fixed* pin assignments seems pretty
useless to me.

And I'd guess that it doesn't matter realy if the source was
in C or ASM...

Jan-Erik.



2005\02\15@074947 by Bob Ammerman

picon face

----- Original Message -----
From: "Wouter van Ooijen" <RemoveMEwouterEraseMEspamEraseMEvoti.nl>
To: "'Microcontroller discussion list - Public.'" <RemoveMEpiclistspam_OUTspamKILLspammit.edu>
Sent: Tuesday, February 15, 2005 3:23 AM
Subject: RE: [PIC] Bug in Microchip mcc18 std library?


>> A quick rat hole - does C18 not allow any pointer to freely
>> point to ROM
>> and RAM ? Would explain some strange constructs in the C18
>> program that
>> I have been converting !
>
> AFAIK is does not.
>
> Wouter van Ooijen

It does not, and for a very good reason. Since ROM and RAM are completely
separate address spaces, that don't even have the same pointer width (RAM =
12 bits, ROM = 16 or 22? bits), there would be quite a bit of overhead to
create 'universal' pointers. I suppose it could be done using a 24-bit
format where the upper bit indicated which memory type to access, but I just
think that would be ugly (and slow).

Bob  Ammerman
RAm Systems


2005\02\15@080625 by Per Linne

flavicon
face
Is there a reason you can't use:

void putrsUSART(const rom char *data)
{
 do
  {  // Transmit a byte
    while(BusyUSART());
    putcUSART(*data);
  } while( *++data );      // <<<<<<<<
}

?

PerL


{Quote hidden}

2005\02\15@082020 by Michael Rigby-Jones

picon face


{Quote hidden}

But speed may be an acceptable trade off sometimes for the convienience
of a function that can accept a pointer to either data or program
memory.  HiTechs compiler can do this, but with a small limitation.  If
the pointer value is below the maximum data memory address, it is deemed
to be pointing to data memory, otherwise it's pointing to program
memory.  Of course this does introduce some overhead and is problematic
if you want to access low program memory with the same pointer.
However, the linker will always place constant data above this address,
so for the majority applications this solution works very well.

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\15@082332 by Michael Rigby-Jones

picon face


{Quote hidden}

Consider what would happen if the pointer were pointing to a NULL
string.  The NULL would be sent, and then the next character (some
random memory address) would be checked.  This is a very dangerous
function, it could potentially send out huge amounts of garbage data.

IMO the value should always be checked BEFORE sending it, not after.

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\15@084035 by Bob Ammerman

picon face

----- Original Message -----
From: "Per Linne" <spamBeGoneper.linneSTOPspamspamEraseMEswipnet.se>
To: "Microcontroller discussion list - Public." <KILLspampiclistspamBeGonespammit.edu>
Sent: Tuesday, February 15, 2005 8:06 AM
Subject: Re: [PIC] Bug in Microchip mcc18 std library?


{Quote hidden}

This breaks (badly) in the case of a null string.

Bob Ammerman
RAm Systems


2005\02\15@084739 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Ake Hedman" <EraseMEakhespamEraseMEeurosource.se>
Subject: Re: [PIC] Bug in Microchip mcc18 std library?


> Who really cares... An experienced programmer will have no problem with
> either form. The
>
> ...
>  } while (*p++);
>
> form will probably be the most common  but I can't see why anyone of
> them should be easier  to read.

While the experienced programmer will be able to read either, the amount of
time it takes is substantially different. When I see the above form, I know
I'm scanning until the end of the string without even thinking about it.

But if I see

   data++;
   } while (*data);

about a million questions come to mind.  Whey did the programmer chooses to
do this so strangely?  Was there supposed to be something after the pointer
is incremented that I missed?  Is my source corrupt?  Is it just that this
guy is really uncomfortable with the language?  If he is, then every other
line is suspect.  Maybe he's a displaced Ada programmer and I should be
looking for Ada idioms insted of C idioms.

Different is rarely better.  In some cases, like user interface, even if
it's better it's not better!  C may have been the first language where
standardization helped a lot.  C is chock full of idioms that allow a very
simple, terse language to be highly effective.  Sure, there are a hundred
ways to do anything, but doing something differently, just for the sake of
being different takes longer for the original programmer, longer for someone
reading it, and makes it more likely that a bug will be missed.

Also, somewhere along this thread, a poster suggested that the optimizations
are the same.  That is absolutely not true.  There is no language for which
optimization has been researched so thoroughly as C.  However, many of the
optimizations rely on recognizing the common idioms.  When the programmer
obfuscates his intent with strained constructs, he makes it less likely that
the compiler will recognize what he is doing.

Now, truth be told, I don't know about C18, and I would hope that is doesn't
go nuts with optimizations.  In an embedded environment, I want to have a
clear picture of what is running in that silicon.  But in many C compilers
these days, the amount of optimization is breathtaking, and attempts to make
the code more efficient will often make it less, by obscuring the
programmer's intent from the compiler.

--McD


2005\02\15@090230 by Hulatt, Jon

picon face

{Quote hidden}

I really wouldn't like the idea of not distinguishing the difference
between the two types of pointer. They *are* different, and IMHO a
compiler "hack" to make them compatible is a recipe for disaster.

For a start, rom pointers are *always* const, ram pointers need not be.
And think of the utter mess of trying to deal with pointers-to-pointers,
ie. void **. Eugh.

2005\02\15@090331 by Sergio Masci

flavicon
face

----- Original Message -----
From: Bob Ammerman <@spam@rammerman@spam@spamspam_OUTverizon.net>
To: Microcontroller discussion list - Public. <spamBeGonepiclistspamKILLspammit.edu>
Sent: Tuesday, February 15, 2005 12:48 PM
Subject: Re: [PIC] Bug in Microchip mcc18 std library?


{Quote hidden}

This is one reason why I added function overloading to XCSB. It is an eligant
solution to the problem of using pointers with different address spaces i.e.
have two (or more) functions that generate code specifically for a pointer of a
given address space.

e.g.
       strcmp(char *str1, char *str2)
and
       strcmp(char *str1, char * const str2)

Previously it was necessary to provide specialised functions to handle pointers
to code space. So "strcmp" have a code space counterpart called "strcmp_code"
but users were free to use an incorrect address space pointer with either
function (RAM space where code space was required). This caused inexperienced
users many problems. Now the compiler not only validates correct pointer use
with parameters, but it also removes the burden from the user by selecting the
correct function based on the parameters supplied.

Another nice thing about function overloading is that it allows further
optimisation of generated code. Consider the C function:

       int SUM(int a, int b)

Any parameters you pass to it must be promoted to "int" before the function is
called. However if you have alternative versions such as:

       int SUM(byte a, byte b)
       int SUM(int a, byte b)
       int SUM(byte a, int b)

Then the compiler is better able to optimise the generated code based on the
parameters supplied to the function. i.e. it fits the function (and the
generated code) to the suplied parameters rather than doing extra work on the
parameters to make them fit the function. Of course this doesn't stop you using
functions as you did before, you are not forced to create functions for every
possible combination of parameters. You just have a lot more control over what
is generated.

Using the "inline" function call stratergy with some overloaded functions and
not others allows you to eliminate function call overheads in cases where the
generated code is less than the code required to call the function while keeping
a single function where the generated code is large.

e.g.
       proc inline byte SUM(byte a, byte b)
               return a + b
       endproc

       proc int SUM(int a, int b)
               return a + b
       endproc

       byte    x, y, z

       x = SUM(y, z)

would generate

       movf    y,w
       movwf    x
       movf    z,w
       addwf    x

whereas

       int    x, y, z

       x = SUM(y, z)

would generate

       movf    y+0,w
       movwf    a_SUM_arg+0
       movf    y+1,w
       movwf    a_SUM_arg+1
       movf    z+0,w
       movwf    b_SUM_arg+0
       movf    z+1,w
       movwf    b_SUM_arg+1
       call    SUM
       movf    result_SUM+0,w
       movwf    x+0
       movf    result_SUM+1,w
       movwf    x+1


Regards
Sergio Masci

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



2005\02\15@091712 by Alan B. Pearce

face picon face
>> Is there a reason you can't use:
>>
>> void putrsUSART(const rom char *data)
>> {
>>  do
>>   {  // Transmit a byte
>>     while(BusyUSART());
>>     putcUSART(*data);
>>   } while( *++data );      // <<<<<<<<
>> }
>>
>> ?
>>
>> PerL
>
>This breaks (badly) in the case of a null string.

For that reason I would have thought the way to do it would be

   while( *data )
      {while(BusyUSART());
       putcUSART(*data++)};

But then I am not experienced with C, so this may still have errors.
   

2005\02\15@093830 by Ake Hedman

flavicon
face
John.

also for me the construct

  data++;
} while (*data);


looks a bit odd  but I have seen o many ways to program from different programmers that I don't bother anymore. Just this construct is not so hard to understand. The other form may however be hard for someone that is new to C but certainly not for someone that is fluid in C.

If the program have comments on things that are not obvious and the code is indented with some form of method (don't care which) its OK. Most professional programmers go through code from other programmers that use a different coding style then they or the group they work in use and as handwriting are different so is coding styles.
It may be just me but there are so many bugs to haunt down and so many things left to do that this isn't worth putting any time on. Anyway thousands of  man hours are spent on this on all companies .IMHO a total waste of time!

Best to add that this  is  just my view of the matter and anyone else have the right to put X% of there time on coding/debugging and X% on formating issues ( replace x and y with the numbers of preference).

And also this is not an attack on you John just general speaking. ;-)

Regards
/Ake

John J. McDonough wrote:

>{Original Message removed}

2005\02\15@094703 by olin_piclist

face picon face
Wouter van Ooijen wrote:
>> C has encouraged a whole generation of programmers to write
>> cutesy obtuse code.
>
> Nobody denies that! But at least they write somewhat *portable* cutesy
> obtuse (that's beyond my knowledge of english, but I can guess) code. C
> is often reffered to as 'the best assembler around', so you of all
> people should love it ;) (and the object code generated by a C compiler
> is in relocateable format!)

You seem to be thinking I was talking about C versus assembler, when I was
really just commenting about C as a language by itself.

It's interesting that the responses I've gotten are mostly along the lines
of "experienced C programmers are used to that".  I'm sure that's true, but
it seems this experience has numbed people to the awful problems inherent in
the system.

It's kindof like you live next to a polluted river.  After a while you don't
notice the smell anymore, and you get used to not swimming in the river or
growing your vegetables by the river bank.  Life goes on and seems normal,
and nobody questions the situation since everything is working fine.  People
from out of town try to point out the deplorable state of affairs, but are
shrugged off since everything is working fine.

I realize a few posts to the PIClist won't change anything, but I wish there
was a way to slap 10,000,000 programmers and get the world to wake up and
see the damage and cost of the "standard" programming language.

I do all my host programming in Pascal.  I'm not saying that's the Right
Answer either, but it certainly is a lot better.  So are many other
alternatives.  I'm the guy from out of town and can't believe how all the
lemmings of Cland can't see the problem.


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

2005\02\15@100100 by Michael Rigby-Jones

picon face
>-----Original Message-----
>From: TakeThisOuTpiclist-bouncesKILLspamspamspammit.edu [.....piclist-bouncesspamRemoveMEmit.edu]
>Sent: 15 February 2005 14:03
>To: Microcontroller discussion list - Public.
>Subject: RE: [PIC] Bug in Microchip mcc18 std library?
>
>
>
>
>I really wouldn't like the idea of not distinguishing the difference
>between the two types of pointer. They *are* different, and IMHO a
>compiler "hack" to make them compatible is a recipe for disaster.
>
>For a start, rom pointers are *always* const, ram pointers need not be.
>And think of the utter mess of trying to deal with
>pointers-to-pointers,
>ie. void **. Eugh.


In Hitech the only type of pointer that can point to both data and
program memory are pointers to const data types.  Are you saying it's
preferable to have two different functions to deal with pointers to
data/program memory rather than one function that can work with either?
e.g. puts() which is used by printf etc.  As sson as you start splitting
things up like this the compiler moves away from ANSI compatibility and
you have to add all sorts of kludges to get things working.

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\15@100653 by Herbert Graf

flavicon
face
On Tue, 2005-02-15 at 14:06 +0100, Per Linne wrote:
> Is there a reason you can't use:
>
>  void putrsUSART(const rom char *data)
> {
>   do
>    {  // Transmit a byte
>      while(BusyUSART());
>      putcUSART(*data);
>    } while( *++data );      // <<<<<<<<
>  }

VERY dangerous. Consider what happens if you call with "", you are
checking the location of something pointing beyond the data you passed
in. TTYL


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\02\15@100931 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: Olin
>Sent: 15 February 2005 14:47
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] Bug in Microchip mcc18 std library?
>

>I do all my host programming in Pascal.  I'm not saying that's
>the Right Answer either, but it certainly is a lot better.  So
>are many other alternatives.  I'm the guy from out of town and
>can't believe how all the lemmings of Cland can't see the problem.

A HHL is only as good as the programmer using it.  It's quite possible
to write completely unmaintainable garbage in Pascal just as you can in
C or virtualy any language.  Assembly language makes writing
unmaintainable garbage a cinch.

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\15@102411 by olin_piclist

face picon face
Michael Rigby-Jones wrote:
> A HHL is only as good as the programmer using it.  It's quite possible
> to write completely unmaintainable garbage in Pascal just as you can in
> C or virtualy any language.

True, but C enforces no discipline and makes it much more likely.  Really
good programmers will write good code in any language.  However, most
programmers are surprisingly sloppy.  It's always amazed my how 99% of all
code is poorly written.

Even good programmers make honest mistakes and typos.  You want the language
such that most simple errors cause illegal syntax, not silently substitute
unexpected behaviour.  I wonder how many millions of dollars have been lost
due to IF (I = 1) being written when IF (I == 1) was really intended.  There
is a very real and large cost to C that nobody seems to notice anymore.


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

2005\02\15@102709 by Hulatt, Jon

picon face
> In Hitech the only type of pointer that can point to both data and
> program memory are pointers to const data types.  Are you saying it's
> preferable to have two different functions to deal with pointers to
> data/program memory rather than one function that can work
> with either?
> e.g. puts() which is used by printf etc.  As sson as you
> start splitting
> things up like this the compiler moves away from ANSI
> compatibility and
> you have to add all sorts of kludges to get things working.
>

The ANSI standard C is designed around an architecture which makes no
distinction in memory between data and code space; the PIC isn't like
that. Whilst it's possible to create an ANSI standard compiler for a
PIC, the architectural quirks, IMO, mean that is less than desireable.

Yes, the side effect is the need for different std functions to cope
with different scenarios, but at least that makes the programmer aware
that there is a very real difference.


2005\02\15@105309 by Michael Rigby-Jones

picon face


{Quote hidden}

When you declare data structures you have to tell the compiler if they
are located in program memory or in data memory.  You then have a handy
pointer that can work with either type of data.  Obviously it is a
pointer to a const data type, so the data cannot be modified via that
pointer even if it is in data memory.  The whole idea is that a function
using this pointer dosen't have to be explicitly told where the data is,
it just works.  Wheres the problem exactly?

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\15@105533 by Michael Rigby-Jones

picon face


{Quote hidden}

That particular example wouldn't be silent however.  Every compiler I
have ever used will emit a warning if you try to do that, and when
dealing with constant comparisons it can be eliminated by reversing the
arguments e.g. if( 1 == I ).  I understand your point, C gives you a
nice long rope with which to hang yourself.  That same rope is very
handy when used properly though.

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\15@110020 by Bob Ammerman

picon face
> In Hitech the only type of pointer that can point to both data and
> program memory are pointers to const data types.  Are you saying it's
> preferable to have two different functions to deal with pointers to
> data/program memory rather than one function that can work with either?
> e.g. puts() which is used by printf etc.  As sson as you start splitting
> things up like this the compiler moves away from ANSI compatibility and
> you have to add all sorts of kludges to get things working.

As long as you have the ability to declare data-constrained and
program-constrained pointers, as well as the 'universal' ones, I guess I am
reasonably comfortable. However, if *every* indirect reference *required*
code to multiplex between code and data, I think I'd find another compiler.

Bob Ammerman
RAm Systems


2005\02\15@111542 by Bob Ammerman

picon face

> When you declare data structures you have to tell the compiler if they
> are located in program memory or in data memory.  You then have a handy
> pointer that can work with either type of data.  Obviously it is a
> pointer to a const data type, so the data cannot be modified via that
> pointer even if it is in data memory.  The whole idea is that a function
> using this pointer dosen't have to be explicitly told where the data is,
> it just works.  Wheres the problem exactly?
>
> Regards
>
> Mike

The problem is that unlike on a PC, for example, the machine language
instructions to access the data in program memory and in data memory are
completely different one from the other. Depending on the PIC, program
memory accesses can be done by using RETLW instructions to define a table,
or via some sort of 'Table Load' instruction. Accessing data memory on the
other hand requires the pointer to be moved into an FSR (and possibly IRP
bits). Constantly checking which is which at runtime is terribly
inefficient. If I wanted that level of performance I'd use Basic ;-) Yech!

Bob Ammerman
RAm Systems




2005\02\15@111603 by ThePicMan

flavicon
face

Olin Lathrop wrote:

>I wonder how many millions of dollars have been lost
>due to IF (I = 1) being written when IF (I == 1) was really intended.

None.. since both produce compile errors.

Since you are putting C under trial, you should at least know that
C statements are case sensitive..


2005\02\15@115529 by olin_piclist

face picon face
ThePicMan wrote:
>> I wonder how many millions of dollars have been lost
>> due to IF (I = 1) being written when IF (I == 1) was really intended.
>
> None.. since both produce compile errors.
>
> Since you are putting C under trial, you should at least know that
> C statements are case sensitive..

OK wiseguy.  I was using case just to make the code stand out from the text
around it, which I suspect you fully understood.  But I'm also not that
familiar with C.  Is it really true that keywords like "IF" are case
sensitive?  In other words, "if" is a keyword and "IF" is an arbitrary
identifier?  That sounds like another set of bugs waiting to happen.

And yes I understand that modern C compilers will flag a warning with "=" in
an IF statement, but I am just trying to illustrate overly lax syntax rules.


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

2005\02\15@122536 by piclist

flavicon
face
On Tue, 15 Feb 2005, Hulatt, Jon wrote:

> However, even without it, my code doesn't work right.
>
> while( *data++ )
> {
>   // Transmit a byte
>   while(BusyUSART());
>   putcUSART(*data);
> }
>
> What the Microchip compiler is doing for that is basically while
> (*(data++)) , so the first char is always missed. My bad. Or is it? I'm
> going to check the text books today to see what the ANSI operator
> precedence should be. I thought that would work.

The problem has nothing to do with operator precedence.  When you
first enter your while loop

while( *data++ )

...you test *data, then increment data.  When you get to
putcUSART(*data), data has already been incremented, and references
the second byte of the string.  I would suggest:

unsigned char ch;

while ((ch = *data++) != 0) {
    while(BusyUSART())
        ;
    putcUSART(ch);
}

This avoids the code size cost of dereferencing the pointer twice.

--
John W. Temples, III

2005\02\15@133009 by Alex Harford

face picon face
On Tue, 15 Feb 2005 11:55:05 -0500, Olin Lathrop
<RemoveMEolin_piclistEraseMEspamspam_OUTembedinc.com> wrote:
>
> In other words, "if" is a keyword and "IF" is an arbitrary
> identifier?  That sounds like another set of bugs waiting to happen.
>

Compile time error at most, since all variables need to be declared at
the top of a function.

Alex

PS you should have a look at Python for your host side programming,
it's a great language for RAD and has tons of toolkits available for
GUIs, networking, etc.

2005\02\15@134013 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Olin Lathrop" <@spam@olin_piclistRemoveMEspamEraseMEembedinc.com>
Subject: Re: [PIC] Bug in Microchip mcc18 std library?


> sensitive?  In other words, "if" is a keyword and "IF" is an arbitrary
> identifier?  That sounds like another set of bugs waiting to happen.

IF is not only an arbitrary identifier, but by convention (but not by rule)
it would be a manifest constant.  It doesn't look anything like if, so it's
hard to see where there is a problem.  What is confusing is when myvariable,
MYVARIABLE,  myVariable, and MyVariable are the same thing.  They don't look
anything alike, and lots of times random case can make things seem to mean
something different.  If they SEEM to mean something different, then they
should mean something different.

I suppose it's all in your upbringing.  A while back I was working over some
Fortran programs, and it was really frustrating dealing with a compiler that
couldn't tell the difference between 0x41 and 0x61.

Very interesting that you are a fan of Pascal, though.  I thought that was
almost extinct.  It's been a long time since I've been much of a fan of the
language for production, but I've always felt that Pascal should be the
first language people learn.  Once someone has been totally immersed in
Pascal it becomes hard for them to write really bad code in any language.

--McD


2005\02\15@135356 by olin_piclist

face picon face
Alex Harford wrote:
>> In other words, "if" is a keyword and "IF" is an arbitrary
>> identifier?  That sounds like another set of bugs waiting to happen.
>
> Compile time error at most, since all variables need to be declared at
> the top of a function.

So are you saying that built in C keywords ARE case sensitive?

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

2005\02\15@135526 by piclist

flavicon
face
On Tue, 15 Feb 2005, Olin Lathrop wrote:

> Is it really true that keywords like "IF" are case
> sensitive?  In other words, "if" is a keyword and "IF" is an arbitrary
> identifier?

Yes, it's really true.  All keywords and identifiers are case-sensitive.

> That sounds like another set of bugs waiting to happen.

Such as?  Weren't you earlier bemoaning C's lack of "discipline", yet
you're asserting case insensitivity is "disciplined"?

--
John W. Temples, III

2005\02\15@143215 by olin_piclist

face picon face
John J. McDonough wrote:
> Very interesting that you are a fan of Pascal, though.  I thought that
> was almost extinct.  It's been a long time since I've been much of a
> fan of the language for production, but I've always felt that Pascal
> should be the first language people learn.  Once someone has been
> totally immersed in Pascal it becomes hard for them to write really bad
> code in any language.

Pascal was originally designed as a teaching language, and I think hit the
mark reasonably well.  However, the pure language as defined by Worth and
Jensen was difficult to use.  It had strong type checking (which is usually
a good thing), but no way out for some reasonable cases.  For example, there
was no way to define a subroutine that accepted a variable length array of
32 bit integers, because the number of subscripts was part of the data type
and there was no way to disable that type checking.

I first encountered Pascal at HP in the early 1980s.  Stuff like the array
passing drove me nuts, and I disliked it and stuck mostly to Fortran.  In
1986 I joined Apollo which had created their own variant of Pascal that
solved most of these silly problems.  Most of Aegis (the Apollo operating
system) was written in this Pascal.  I got to like the Apollo
implementation.

A few years later after Apollo I was stuck with the problem of making a
large graphics intensive application that was running on Apollos run on
other workstations.  I knew this was coming, and had envisioned doing a
one-time conversion from Pascal to C and then going forwards in C.  When the
time came, I read the C manual and gagged.  There were so many useful things
I could explain to the Pascal compiler that couldn't be explained to C that
it would have been a giant step backwards for the code base.

Instead we decided to write a translator that would translate the Pascal to
whatever the best language was on each target system, compile in that
language, then throw out the intermediate source and keep the binary.  This
worked very well.  In the end it turned out to be very useful to have a
translation step between our code and the code the end compiler got,
regardless of converting between languages in the process.  Each of the
target compilers had its own bugs and slightly different ways of dealing
with some system issues.  We could implement work arounds for these issues
in the translator back end.

In the process we also extended the Apollo Pascal definition in some places
and ignored other parts.  Most of these differences were to support writing
portable code accross different machine and operating system types.

I've continued writing in Pascal and using the translator ever since.  The
translator is called SST, and is actually included in the PIC programmers
development software release at http://www.embedinc.com/picprg/sw.htm.


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

2005\02\15@144023 by olin_piclist

face picon face
piclist@xargs.com wrote:
> Such as?  Weren't you earlier bemoaning C's lack of "discipline", yet
> you're asserting case insensitivity is "disciplined"?

It depends on how you think of it.  Good syntax rules make it more likely
that minor typos become illegal, and that casual observers won't be misled.
Case sensitivity is just asking for someone to create two variables called
BigOats and BiGoats.  I can also see how "IF" versus of "If" could get
easily missed by a reviewer.


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

2005\02\15@150642 by Robin Abbott

flavicon
face
Well our compiler allows pointers to freely point to ROM or RAM by using
the top bit to show ROM or RAM. Of course that means a maximum of
32Kwords of ROM can be addressed by the ROM pointer. We handle this by
putting all constant data in the bottom 32K of ROM and allowing the user
to define functions to which pointers must be created as "pointed". This
is only necessary on devices with more than 32K words of ROM.

I happen to think that having to call 2 versions of every function
dependant on whether a pointer is to ROM or RAM is very messy.

Robin Abbott

Forest Electronic Developments

01590 681511
+44 1590 681511 (phone/fax)

See our web pages : http://www.fored.co.uk



{Original Message removed}

2005\02\15@152201 by Rob Young

picon face
> Alex Harford wrote:
>>> In other words, "if" is a keyword and "IF" is an arbitrary
>>> identifier?  That sounds like another set of bugs waiting to happen.
>>
>> Compile time error at most, since all variables need to be declared at
>> the top of a function.
>
> So are you saying that built in C keywords ARE case sensitive?
>

They are case sensitive.  However it is possible that a compiler's author(s)
could have been lazy and don't care about "if" vs "IF" vs "If" vs "iF"...

Likewise, "BigOat" is different from "BiGoat" because variables are supposed
to be case sensitive.  But again, a lazy compiler writer might ignore the
differences.

There are compiler dependent differences in how many letters are actually
used from the variable name.  It has been my experience that at least the
first 64 are reconginzed by the "major" players in C compilers.  And unless
you are a hopeless Hungarian Notation freak, how often are your variable
names longer than 64 characters anyway?  Personal opinion, but if you need
more than 64 characters to describe your variable or object, seek help.

Rob Young

2005\02\15@152209 by D. Jay Newman

flavicon
face
> So are you saying that built in C keywords ARE case sensitive?

All identifiers in standard C are case sensitive.

On the other hand, I prefer languages to be case insensitive *and*
case preserving. This is much like the file systems on Windows and Macintosh
computers. It is also closer to how people think. Case is an artifact of
some forms of writing.
--
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\15@152405 by Marcel van Lieshout

flavicon
face
I couldn't agree more. I am currently porting an rtos from mcc18 to wizC and
I must say it's a joy the way things are handled by Robin's compiler.

Robin Abbott wrote:
{Quote hidden}

> {Original Message removed}

2005\02\15@154021 by piclist

flavicon
face
On Tue, 15 Feb 2005, Olin Lathrop wrote:

> Case sensitivity is just asking for someone to create two variables called
> BigOats and BiGoats.

And how is this different from BigOats vs. Big0ats in a
case-insensitive language?  The fact that you *can* create variables
with confusing names doesn't meant you're going to *accidentally* do
so.  Bad practice transcends language.

But if a language lets me randomize the spelling of BigOats, I've
simply added a confusion factor for a reviewer since I'm not required
to be disciplined in my capitalization.

> I can also see how "IF" versus of "If" could get easily missed by a reviewer.

I don't think anyone is going to be reviewing code that hasn't been
compiled, and "IF" vs. "If" is not going to be missed by a compiler.

--
John W. Temples, III

2005\02\15@163009 by James Newton, Host

face picon face

> > Case sensitivity is just asking for someone to create two variables
> > called BigOats and BiGoats.
>
> And how is this different from BigOats vs. Big0ats in a
> case-insensitive language?  The fact that you *can* create
> variables with confusing names doesn't meant you're going to
> *accidentally* do so.  Bad practice transcends language.

For anyone who missed it, the second variable name above has a zero in it.

I try to make sure I program in a font that differentiates between 0 and O,
l and 1, 5 and S, and has enough space between the letters to prevent
confusing rn with m.

For what it's worth, case sensitivity is just a way for a compiler (and its
author) to do less work. As much as it pains me to say it, the IDE for
Visual Basic is fantastic and handling this... Are any of the PIC IDEs like
that?

This thread is very nearly not PIC related...

...if we continue with language wars, I would appreciate it if the tag
changed to [EE].

---
James Newton: PICList webmaster/Admin
@spam@jamesnewtonspam_OUTspam.....piclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



2005\02\15@165421 by Wouter van Ooijen

face picon face
> Yes, it's really true.  All keywords and identifiers are
> case-sensitive.
>
> > That sounds like another set of bugs waiting to happen.

No, I have never seen a problem related to the case-sensitiveness of the
keywords. Not even in beginners' 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\15@165421 by Wouter van Ooijen

face picon face
> >I wonder how many millions of dollars have been lost
> >due to IF (I = 1) being written when IF (I == 1) was really intended.
>
> None.. since both produce compile errors.
>
> Since you are putting C under trial, you should at least know that
> C statements are case sensitive..

Hmmmmm. Perfectly vaild but very pointless remark. The above *is* a
major problem in C. But most C *compilers* will at least give a warning.
Provided that the compiler does not also produce a mess of useless
warnings, this mostly solves the problem.

C is a lot like the PC architecture or the 14-bit PIC architecture: a
total mess, but so bloody cheap and easily available that you will
probably want to use it regardless.

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\15@165421 by Wouter van Ooijen

face picon face
> You seem to be thinking I was talking about C versus assembler

I was mainly have fun. I think most C programmers are well aware of the
problems of the language, but in a lot of cases those problems still
outweight the advantages (or rather: the alternatives have more
problems).

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\15@165422 by Wouter van Ooijen

face picon face
> That's pretty much what i've now decided to do.
>
> I did previously get the LCD lib working (with an lcd you supplied me,
> no less!), but to have to recompile the libraries to match
> the pin/port
> configuration you're using seems a bit c**p to me.

That's why I never use object libraries. In my main file I put some
#defines that define the pins used, next I include the library source.
(yes: #include <lcd.c>). This is against the lore, but that lore was
established when computer memories were small, recompilation took a lot
of time, and the linker was much faster than the compiler. Times have
changed.

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\15@190820 by olin_piclist

face picon face
James Newton, Host wrote:
> For what it's worth, case sensitivity is just a way for a compiler
> (and its author) to do less work. As much as it pains me to say it,
> the IDE for Visual Basic is fantastic and handling this... Are any of
> the PIC IDEs like that?

At least with MPASM you can disable case sensitivity.  I always use it with
case sensitivity disable.  It saves a lot of messing with the SHIFT key to
type SFR names, which are all defined in upper case in the standard include
files.


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

2005\02\15@222211 by Jake Anderson

flavicon
face
>
> For what it's worth, case sensitivity is just a way for a
> compiler (and its
> author) to do less work. As much as it pains me to say it, the IDE for
> Visual Basic is fantastic and handling this... Are any of the PIC
> IDEs like
> that?
>
> This thread is very nearly not PIC related...
>
> ...if we continue with language wars, I would appreciate it if the tag
> changed to [EE].

personally I love VB's IDE
I make great use of the way it deals with case as a pre-emptive bug catcher.
when I create a variable I capitalise it appropriately
dim BigGoatsName as string

then when I type a line of code I do it all in lower case
if biggoatsname = "fred" then msgbox("The goats name is fred")

becomes
Dim BigGoatsName As String
If BigGoatsName = "fred" Then MsgBox ("The goats name is fred")

when you press enter it will capitalise biggoatsname the same as it was in
the dimension, and highlight all the keywords, you know you havent messed
up.
I don't know how many typos and misnamings this has caught, now if only I
can get it to highlight in red lines which fail syntax without popping up
the window.

2005\02\15@223711 by andrew

picon face
"option explicit" helps too.. turns on requiring definitions

andrew


----- Original Message -----
From: "Jake Anderson" <spamBeGonegrooveeeEraseMEspamoptushome.com.au>
To: "Microcontroller discussion list - Public." <piclistspamBeGonespammit.edu>
Sent: Tuesday, February 15, 2005 10:22 PM
Subject: RE: [EE] Bug in Microchip mcc18 std library?


{Quote hidden}

catcher.
{Quote hidden}

> --

2005\02\16@002832 by William Chops Westfield

face picon face
On Feb 15, 2005, at 8:55 AM, Olin Lathrop wrote:

> I am just trying to illustrate overly lax syntax rules.
>
Almost all languages have ways to shoot yourself in the foot.
Languages that have gone to a lot of trouble to eliminate such
foot-shooting-mechanisms have found themselves rejected and
ridiculed  (I'm specifically thinking of Ada here, but the pascal
variants like modula2 come close too, I think.)

It HAS been amusing to watch C "take over the world" in spite
of all those other efforts.  I can only conclude that somehow
C managed to hit the 'sweet spot' of the power/danger curve.

To be fair, its worth pointing out that a lot of C's current
usefulness seems to come from breaking assumption of the original
language in favor of greater safety.  The latest versions of
compilers check printf arguments against the formatting string,
despite the fact that that is deep library knowledge, not only
not part of the C language, but not SUPPOSED to be part of the
language.  But still useful :-)

BillW

2005\02\16@052041 by Jan-Erik Soderholm

face picon face
Olin Lathrop wrote :

> At least with MPASM you can disable case sensitivity.  I
> always use it with case sensitivity disable.  It saves a
> lot of messing with the SHIFT key to type SFR names,
> which are all defined in upper case in the standard include
> files.

Right, after removing the double defined (upper *and* lower
case) SFR names in some of the device include files... :-)

Jan-Erik.



2005\02\16@071040 by Peter L. Peres

picon face


On Tue, 15 Feb 2005, Per Linne wrote:

{Quote hidden}

That code fails if the first character is NUL

Peter

2005\02\16@082950 by Per Linne

flavicon
face
I know I know... Thank you all.

My point was the OP:s reasoning about post increment.
I thought that noone seemed to point out the existence of
the pre increment alternative. My intention was not to provide
the perfect solution to the problem. On the other hand why would
anyone write a null string to a function in an embedded application.
But of course: Better safe than sorry...

After all I got the impression that it started out with M:chips
mcc18 std library and it suffers the same pitfall when it comes
to null strings. Doesn't it.

Regards,
PerL

PS 70 percent of my (full) time I write C and C++ programs and
have a few products out there. Of course I make misstakes and
ugly fast things now and then. And sometimes I have to trace
bugs to. That bad am I. :-)


{Original Message removed}

'[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
RemoveMEjayspamspamBeGonesprucegrove.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" <spamBeGonepeterKILLspamspam@spam@elemental.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
<mcdspam_OUTspam@spam@is-sixsigma.com> wrote:
> ----- Original Message -----
> From: "Peter Johansson" <spamBeGonepeter@spam@spamelemental.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
RemoveMEjayEraseMEspamKILLspamsprucegrove.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
spamBeGonejayspam_OUTspamRemoveMEsprucegrove.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}

'[PIC] Bug in Microchip mcc18 std library?'
2005\02\16@155606 by Peter L. Peres

picon face


On Tue, 15 Feb 2005, Olin Lathrop wrote:

> OK wiseguy.  I was using case just to make the code stand out from the text
> around it, which I suspect you fully understood.  But I'm also not that
> familiar with C.  Is it really true that keywords like "IF" are case
> sensitive?  In other words, "if" is a keyword and "IF" is an arbitrary
> identifier?  That sounds like another set of bugs waiting to happen.
>
> And yes I understand that modern C compilers will flag a warning with "=" in
> an IF statement, but I am just trying to illustrate overly lax syntax rules.

Imho the only bug in C is that it has a stoopid string end encoding
convention that supplies about 50% of the proverbial rope to pointer &
string users.

As to confusing C code, there is a contest for 'obfuscated C'. The
following code is a BASIC interpreter (!) that won first prize once. I
took a few hours to pick it apart once. Most instructive code. Obviously
one is not supposed to code like that ;-)

Code by Diomidis Spinellis:
-- start --
#include <stdio.h>
#define Q r=R[*p++-'0'];while(
#define B ;break;case
char*s="Qjou!s\\311^-g\\311^-n\\311^-c\\::^-q-ma%mO1JBHm%BQ-aP1J[O1HB%[Q<nbj\
o)*|gps)<<*txjudi)m*|aQdbtf!::::;sfuvso<aQefgbvmu;aQ<m,,a%CQ<csfbla%bQ<aN2!Q\
\ndbtf!aP2Q;m>aP2Q<a%!D12J!JGJHJOJQJFJSJJJMHS%HD12D12N3!N4\nJUJT%UQm>aP4HC%T\
Qs\\q,,^>m,2<m>aP4HC%SD12N1\nJNQm>s\\..q^aHC%NHb%GN1!D32P3%RN1UP1D12JPQUaP1H\
R%PN4\nQ<g\\(aP3Q(^>aP2Q,2<n\\(aP3Q(^>aP4Hb%OD12D12N2!N3\nJVP3Q,,<jg)aP3Q=>n\
\\(aP3Q(^*m>g\\(aP3Q(^<fmtf!m,,aHC%QN1!N1\nJ#Qqsjoug)#&e]o#-aP1Q*aHb%#Qqvut)\
aP1Q*aHb%FN1\nQm>::::aHC%VP3Q>bupj)hfut)c**aHb%JD12JON1!Qjg)a%LN1UP1D12JIQUa\
P1HL%IQ*m>aN2!N2\nP2Q<fmtf!m,,aHC%MN1!N2>P2Q>aN2\nP2Hbdd!b/d";k;char R[4][99]
;main(c,v)char**v;{char*p,*r,*q;for(q=s;*q;q++)*q>'
'&&(*q)--;{FILE*i=fopen(v[1],"r"),*o=fopen(q-3,"w");
for(p=s;;p++)switch(*p++){B'M':Q(k=fgetc(i))!=EOF
&&k!=*p)*r++=k;if(k==EOF){fputs("}}\n",o);fclose(o);return
system(q-6);}*r=0B'P':while(*p!='`')fputc(*p++,o)B'O':Q*r)fputc(*r++,o);p--B'C':k=0
;Q k<*p-'0')(*r++=fgetc(i),k++);*r=0 B'I':k=*p;if(**R==k)goto G B'G':k=*p;
G:p=s;while(*p!='$'||p[1]!= k)p++;p++B'N':R[*p-'0'][0]++;}}}
--end--

(this rendering does not do the original justice, the original was a
compact block of text, my MUA broke it up, so this version probably
won't compile easily)

When compiled, the program correctly interprets a game called LANDER.BAS
which you can find on the internet. You can find more references by
looking for 'obfuscated c' in a search engine.

Peter

'[EE] Languages, was Bug in Microchip mcc18 std lib'
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

'[PIC] Bug in Microchip mcc18 std library?'
2005\02\16@162038 by Peter L. Peres

picon face


On Tue, 15 Feb 2005, Olin Lathrop wrote:

> Alex Harford wrote:
>>> In other words, "if" is a keyword and "IF" is an arbitrary
>>> identifier?  That sounds like another set of bugs waiting to happen.
>>
>> Compile time error at most, since all variables need to be declared at
>> the top of a function.
>
> So are you saying that built in C keywords ARE case sensitive?

ALL identifiers *and* keywords (there exactly 32 keywords in C - C is a
RISC language in a way) are case sensitive. Additionally, you cannot use
ANY keyword as an identifier, ever.

Peter

2005\02\16@162433 by Peter L. Peres

picon face


On Tue, 15 Feb 2005, Olin Lathrop wrote:

> .....piclistspamRemoveMExargs.com wrote:
>> Such as?  Weren't you earlier bemoaning C's lack of "discipline", yet
>> you're asserting case insensitivity is "disciplined"?
>
> It depends on how you think of it.  Good syntax rules make it more likely
> that minor typos become illegal, and that casual observers won't be misled.
> Case sensitivity is just asking for someone to create two variables called
> BigOats and BiGoats.  I can also see how "IF" versus of "If" could get
> easily missed by a reviewer.

The reviewer is usually lint (a C source checker). It, and the
compiler's built-in syntax checking will locate most errors. Also, there
is no such thing as an automatically allocated variable name in C. Each
variable name is declared by the user and its scope is strictly
controlled, inside a paragraph of source, a function, local to a
specific source file, or to the whole program.

Peter

'[EE] Languages, was Bug in Microchip mcc18 std lib'
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

'[PIC] Bug in Microchip mcc18 std library?'
2005\02\16@163629 by Wouter van Ooijen

face picon face
> Imho the only bug in C is that it has a stoopid string end encoding
> convention that supplies about 50% of the proverbial rope to
> pointer & string users.

That's only 10% a C language feature, and 90% a C *library* feature. It
has no influence on pointer use except for pointers into 0-terminted
strings. And if you consider that the biggest problem in C your
definitely on your own. Come to my classes and assist me to help the
students with all the other nice features of C!

And if you want to read a real expert check
www.amazon.com/exec/obidos/ASIN/0201543303/103-1785716-4999000.
But note that even though he disliked a lot about C he changed nearly
nothing in the extension to 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


'[EE] Languages, was Bug in Microchip mcc18 std lib'
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

'[PIC] Bug in Microchip mcc18 std library?'
2005\02\16@231237 by Bob Ammerman

picon face
> ALL identifiers *and* keywords (there exactly 32 keywords in C - C is a
> RISC language in a way) are case sensitive. Additionally, you cannot use
> ANY keyword as an identifier, ever.
>
> Peter

Unless you do the utterly reprehensible thing of #defining them to something
else :-)


#define if  aa

int if = 10;

while ( if-- )
   n += if;


Evil, huh?

Bob Ammerman
RAm Systems


'[EE] Languages, was Bug in Microchip mcc18 std lib'
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" <wouterspam@spam@voti.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" <EraseMEA.B.PearceRemoveMEspamSTOPspamrl.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" <RemoveMEwestfwKILLspamspamTakeThisOuTmac.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@082525 by Walter Banks

picon face
There was an 11/03 with a 8 inch floppy. that loaded the microcode for the VAX instruction. There earliest VAX's didn't do anything with read errors on the floppy. I spent an interesting Saturday trying to find out why when I ran some programs in
compatibility mode (PDP11) that some of the conditional branches did not appear to work. There was an unreported microcode load error. The disk drive for the microcode was inside one of the cabinets and that was the first time I knew how the microcode was
loaded. Later when some of my friends wanted to rewrite the microcode I wrote a micro code assembler.

Digression on
Some of the other PDP-11's were microcoded. The 11/03 was and so was some of the other later larger PDP-11's processors . The original PDP-11 (PDP-11/20) had a hardwired ALU using TTL and 74181's for math functions. Western digital that manufactured the
11/03 chip set recoded the microcode to support the UCSD intermediate P code.

There are still a couple PDP-11's at Byte Craft in our historical products center (aka Junque Room). There is an old PDP 11/04 and a Terek 8510 (PDP-11/03 chipset running PDP-11 instruction set. A personal computer that was shipped with the UCSD P
system). The Terek was booted a couple years ago the PDP-11/04  was last powered up 6 or 8 years ago. (Removable hard drive was 2.5 Mbytes and the size of a large Pizza )

Digression off

w..





"Alan B. Pearce" wrote:

{Quote hidden}

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" <spamBeGonejon.hulattspam@spam@monster.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_OUTspammit.edu [piclist-bouncesspamspammit.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" <rammermanspamBeGonespam.....verizon.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.hulattspam.....monster.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

'[PIC] Bug in Microchip mcc18 std library?'
2005\02\17@140657 by Peter L. Peres

picon face


On Wed, 16 Feb 2005, Bob Ammerman wrote:

{Quote hidden}

That assumes that no if is used as a keyword in the program, no ?

Peter

'[EE] Languages, was Bug in Microchip mcc18 std lib'
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" <spam_OUTmscovillespamKILLspamunicontrolinc.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 <RemoveMEplpRemoveMEspamEraseMEactcom.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 <KILLspamplpspamspamBeGoneactcom.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" <roywardspamspamphysics.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 <RemoveMEjoecolquittspamBeGonespamRemoveMEclear.net.nz>
To: Microcontroller discussion list - Public. <KILLspampiclistspamBeGonespammit.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" <@spam@mscovilleSTOPspamspam@spam@unicontrolinc.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 Richard.ProsserspamBeGonespamspamBeGonePowerware.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 <spam_OUTbyronSTOPspamspamcc.gatech.edu>
To: Microcontroller discussion list - Public. <RemoveMEpiclistspamspammit.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
TakeThisOuTjayspamspamRemoveMEsprucegrove.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
KILLspamjayspamspamspam_OUTsprucegrove.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
jayRemoveMEspamsprucegrove.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" <EraseMEgrooveeeSTOPspamspamRemoveMEoptushome.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
spam_OUTjayRemoveMEspamEraseMEsprucegrove.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 <TakeThisOuTlistsRemoveMEspam@spam@connectionbrazil.com>
To: Microcontroller discussion list - Public. <EraseMEpiclistRemoveMEspammit.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" <.....grooveeespamspam.....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" <wouterKILLspamspamEraseMEvoti.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@105413 by Walter Banks

picon face
The interpreter is ROM overhead. In a study we did here in the early 90's we found that
there were very few cases where the resulting hybrid application would require less ROM
in real applications except for those with a lot of multibyte or float data types.

w..


Gerhard Fiedler 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
>
> Basically, it is a compiler that can generate both compiled code (fast) and
> interpreted (small) code.


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@111338 by Walter Banks

picon face
Look very closely at the ISO C standards for embedded systems. It is heading this way
with language support for a single application and single source running on many
sometimes different CPU's

The current automotive engine controllers have three processors (Two different
architectures) and are created from a single build that passes interface information
and variable allocation between code segments.


w..



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


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.





'[EE] selecting the right C++ STD library memory bu'
2006\02\24@192828 by James Newtons Massmind
face picon face
The programmer I hired to help with this is sick and make take some time to
reply so I'll write the list with this question in hopes of finding an
answer faster.

I'm writing Win32 code in C/C++ (MS Visual C++ 2005 Express Edition) and
part of this code manipulates data that is handed to it in a memory buffer.
I may have to insert things and thereby increase the size of the data beyond
the size of the source buffer. So I need to allocate a buffer of my own,
copy from the source and insert my bits, the return the result in place of
the source. No problems so far.

The issue is what class to use for my buffer. Here are the requirements:
1. It should be as efficient and fast as possible. E.g. I don't need file IO
so there is no reason to use a iostream class.

2. The data is binary. By that I mean the byte values will range from 0 to
255. Some of the data I will put into the buffer is binary, but other data
will be text and some data will be binary values (int, short, etc...) that I
will need to convert to decimal characters and append. E.g. if it was an
std::basic_stringstream I would use:

std::basic_stringstream<wchar_t> buffer;
int I = 123;
buffer << "I is:" << I;

So the issue is this combination of needs: copying in parts of a binary char
array, text, or decimal values of variables.

What class does all that? And more importantly, where is there any
documentation that would help a poor newbie like me figure out what they do
and don't?

I've been advised to use vector but that doesn't support the << and the copy
as far as I can see.

I've also been advised not to use streams as they don't play well with
binary?

Any advice appreciated.

---
James Newton: PICList webmaster/Admin
EraseMEjamesnewton@spam@spam@spam@piclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2006\02\24@224458 by Chris Levin

flavicon
face
James Newtons Massmind wrote:

{Quote hidden}

Take a look at the ArrayList class. It can do the things you need. It
can grow dynamcially, it takes any object types  and it can be efficient
in speed and memory. Check out the documentation to see how it's used
and see some samples. That will let you know for sure if it meets your
needs.

-Chris

2006\02\27@105157 by William Killian

flavicon
face


> -----Original Message-----
> From: spamBeGonepiclist-bouncesRemoveMEspamEraseMEmit.edu [RemoveMEpiclist-bouncesKILLspamspamRemoveMEmit.edu] On
Behalf
> Of James Newtons Massmind
> Sent: Friday, February 24, 2006 7:28 PM
> To: 'Microcontroller discussion list - Public.'
> Subject: [EE] selecting the right C++ STD library memory buffer
>
> The programmer I hired to help with this is sick and make take some
time
> to
> reply so I'll write the list with this question in hopes of finding an
> answer faster.
>
> I'm writing Win32 code in C/C++ (MS Visual C++ 2005 Express Edition)
and
> part of this code manipulates data that is handed to it in a memory
> buffer.
> I may have to insert things and thereby increase the size of the data
> beyond
> the size of the source buffer. So I need to allocate a buffer of my
own,
> copy from the source and insert my bits, the return the result in
place of
> the source. No problems so far.
>
> The issue is what class to use for my buffer. Here are the
requirements:
> 1. It should be as efficient and fast as possible. E.g. I don't need
file
> IO
> so there is no reason to use a iostream class.
>
> 2. The data is binary. By that I mean the byte values will range from
0 to
> 255. Some of the data I will put into the buffer is binary, but other
data
> will be text and some data will be binary values (int, short, etc...)
that
> I
> will need to convert to decimal characters and append. E.g. if it was
an
> std::basic_stringstream I would use:
>
>  std::basic_stringstream<wchar_t> buffer;
>  int I = 123;
>  buffer << "I is:" << I;
>
> So the issue is this combination of needs: copying in parts of a
binary
> char
> array, text, or decimal values of variables.
>
> What class does all that? And more importantly, where is there any
> documentation that would help a poor newbie like me figure out what
they
> do
> and don't?
>
> I've been advised to use vector but that doesn't support the << and
the
> copy
> as far as I can see.

Derive a class from any of the C++ STL and you can add any features you
want.

One of the annoying things about C++ is that they broke some of the
simplicity of C.  What do you want << to mean?  Do you mean send the
whole structure to an iostream?  Binary shift some or all of the
elements?

All C++ STL container classes can be copied.  What do you mean by that?

> I've also been advised not to use streams as they don't play well with
> binary?

Depends what you mean by play nice.  I use binary elements into streams
all the time.


>
> Any advice appreciated.

STL container type choice depends upon what the most common operation
is.

I can help you with this on or off list but I'd need a better
specification of exactly what kind of data you want to handle.

Is it this sort of stuff?  This was a five minute type in using Visual
Studio.Net  (even though I hate .net)

// CharList.cpp : Defines the entry point for the console application.
//

#include <list>
#include <iostream>

typedef std::list < unsigned char > charList;

unsigned char a [] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
unsigned char b [];

int main(int , char* )
{
       charList l;

       for (unsigned idx = 0; idx <= sizeof(a); ++idx)
       {
               // an insert before for no particular reason
               if ( a [idx] == 2)
               {
                       l.push_back(2);
               }
               l.push_back ( a [idx] );

               // an insert after again for no aprticular reason
               if (a [idx] == 7)
               {
                       l.push_back( 11 );
               }
       }

       for ( charList::iterator itr = l.begin();
               itr != l.end();
               ++itr )
       {
               if ( *itr == 6 )
               {
                       l.insert ( itr, 250 );
               }
       }

       for ( charList::const_iterator itr = l.begin();
                 itr != l.end();
                 ++ itr)
       {
               std::cout << (unsigned)*itr << std::endl;
       }

       return 0;
}



-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
TakeThisOuTpostmasterspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\27@142905 by James Newton, Host

face picon face
<snip>

> >I may have to insert things and thereby increase the size of
> the data
> >beyond the size of the source buffer. So I need to allocate
> a buffer of
> >my own, copy from the source and insert my bits, the return
> the result
> >in place of the source. No problems so far.
> >
> >The issue is what class to use for my buffer. Here are the
> requirements:
> >1. It should be as efficient and fast as possible. E.g. I don't need
> >file IO so there is no reason to use a iostream class.
> >
> >2. The data is binary. By that I mean the byte values will
> range from 0
> >to 255. Some of the data I will put into the buffer is binary, but
> >other data will be text and some data will be binary values (int,
> >short, etc...) that I will need to convert to decimal characters and
> >append.

<snip>

> Take a look at the ArrayList class. It can do the things you
> need. It can grow dynamcially, it takes any object types  and
> it can be efficient in speed and memory. Check out the
> documentation to see how it's used and see some samples. That
> will let you know for sure if it meets your needs.

Thanks for the advice, but ArrayList seems to keep a series of separate
arrays each as an entry in a list. I need something that can be returned as
a solid, contiguous block of memory. I have to return a pointer to a large
array of characters and I'm trying to find easy ways to append thing to the
end of that array.

I guess I was under the impression that C++ actually made things /easier/ to
do than what was available in just C. It appears that C++ gives you many
more interesting things that you can do, but they are all more complex and
so far as I can see actually /more/ difficult.

Just for the sake of discussion and to see if there are any other points of
view out there...

In VB or something like that I could just do

i = 0
S = s & "hello" & Chr(i) & CStr(i) & Chr(27)
REM the CStr probably isn't required, but makes it more clear.

And I would have a buffer with the following hex values in it:
68 65 6C 6C 6F 00 30 1b
"h "e "l "l "o  i (i)27

In Perl, I would use the pack function:

$i = 0;
$s = pack("AXCAXC", "hello", $i, $i, "\x1b");
# the X after the A "backs up" the result to overwrite the space
# which is added by default after an ASCII string.

The equivalent code in C is something like

char I = 0;
char s[999];
char *si = s;

si = strcpy( *si, "hello");
*si++ = i;
si += sprintf( *si, "%c", i);
*si++ = 0x1b;

And I've probably made some stupid mistake there as I'm a little rusty on C
code. The problem with that is that the buffer may grow very large and so
the dynamic increase in size of the vector class in C++ is really nice. But
as far as I can see, you can only use .push_back(char) to add one character
at a time to the buffer. To add strings and decimal values, I apparently
have to write some abortion like this?

typedef std::vector<char> buffer;
typedef std::istreambuf_iterator<buffer::value_type> bufiter;
   
buffer s;
char i = 0;
std::basic_stringstream<char> temp1;
std::basic_stringstream<char> temp2;

temp1 << "hello";
std::copy(bufiter(temp1),bufiter(),std::back_inserter(s));
s.push_back(i);
temp2 << i;    
std::copy(bufiter(temp2),bufiter(),std::back_inserter(s));
s.push_back(0x1b);

But at least I can keep doing stuff like that as long as I want... And with
a good C++ compiler, that will run pretty fast. Of course, something has to
be done about the temp variables as I can't for the life of me seem to find
a method that clears out a basic_stringstream to allow it to be reused...

But this can NOT be right, right? The C++ standard library must have made it
easier to append text, binary values, and decimal conversions of values to a
contiguous array of characters? It just can NOT be that Visual Basic is
better for this...

P.S. If someone will check my C (and other) code and post the corrections,
I'll put this up on the web site as an example of how to do the same basic
thing in VB, Perl, C and C++

---
James Newton: PICList webmaster/Admin
spamBeGonejamesnewtonKILLspamspamTakeThisOuTpiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2006\02\27@143814 by James Newton, Host

face picon face
> > I've been advised to use vector but that doesn't support the << and
> the
> > copy
> > as far as I can see.
>
> Derive a class from any of the C++ STL and you can add any
> features you want.

Ahh... Well... Probably beyond me at this point.

> One of the annoying things about C++ is that they broke some
> of the simplicity of C.  What do you want << to mean?  Do you
> mean send the whole structure to an iostream?  Binary shift
> some or all of the elements?

It is confusing, yes...

> All C++ STL container classes can be copied.  What do you
> mean by that?

How do I copy something into a std:vector other than looping through it one
character at a time and using push_back? Or better yet, see the other post I
just sent on this subject.

> > I've also been advised not to use streams as they don't
> play well with
> > binary?
>
> Depends what you mean by play nice.  I use binary elements
> into streams all the time.

www.sunsite.ualberta.ca/Documentation/Gnu/libstdc++-2.90.8/html/27_io
/howto.html but again, I don't really need io, so it seems wastefull to use
a class that supports it.

> > Any advice appreciated.
>
> STL container type choice depends upon what the most common
> operation is.
>
> I can help you with this on or off list but I'd need a better
> specification of exactly what kind of data you want to handle.

Best to see my other post as it gives an example that (I hope) makes it more
clear.

Thanks for responding...

---
James Newton: PICList webmaster/Admin
EraseMEjamesnewton.....spamKILLspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2006\02\27@170415 by William Killian

flavicon
face


> -----Original Message-----
> From: spampiclist-bouncesspammit.edu [piclist-bouncesSTOPspamspammit.edu] On
Behalf
{Quote hidden}

need
> > >file IO so there is no reason to use a iostream class.
> > >
> > >2. The data is binary. By that I mean the byte values will
> > range from 0
> > >to 255. Some of the data I will put into the buffer is binary, but
> > >other data will be text and some data will be binary values (int,
> > >short, etc...) that I will need to convert to decimal characters
and
{Quote hidden}

separate
> arrays each as an entry in a list. I need something that can be
returned
> as
> a solid, contiguous block of memory. I have to return a pointer to a
large
> array of characters and I'm trying to find easy ways to append thing
to
> the
> end of that array.
>
> I guess I was under the impression that C++ actually made things
/easier/
> to
> do than what was available in just C. It appears that C++ gives you
many
> more interesting things that you can do, but they are all more complex
and
> so far as I can see actually /more/ difficult.
>
> Just for the sake of discussion and to see if there are any other
points
{Quote hidden}

This will work in C++ nearly all C programs are C++ programs as well.



>
> And I've probably made some stupid mistake there as I'm a little rusty
on
> C
> code. The problem with that is that the buffer may grow very large and
so
> the dynamic increase in size of the vector class in C++ is really
nice.
> But
> as far as I can see, you can only use .push_back(char) to add one
> character
> at a time to the buffer. To add strings and decimal values, I
apparently
{Quote hidden}

Istreams suck.  Use the C I/O most of the time.  It's all still there.
Don't use the "basic_XX" stuff - use the more specialized ones that
match your needs.  You want 8 bit ascii use stringstream NOT
basic_stringstream.  You want wchar_t instead of char use wstringstream.

To match your C above - it makes more sense than your C++:

I'll assume cases mismatches were unintentional and you email like mine
'corrects' things it shouldn't...  

And that I is a char intended to first be added as NUL I think you
duplicated code in the C with '*si++ = i and the ssprintf version

Did you mean to put a 0x00 followed by 0x30?  Or 0 as binary and 0 as
ACII?  Lets assume you did.  You should have used a %d not %c for that

stringstream (#include <sstream>) might be what you want.



// replaces char s[] AND char * si

std::string stream ss;
// char I = 0 from your code?
Const char esc = 0x1B;
char i = 0;

// A char goes through as 'binary' while an int is converted to ASCII

ss << "hello";        // Add hello as text
ss << i;                // Add I as a NULL single byte 0
ss << (int)i;        // Add I as an ASCII string or 0x30
ss << esc;                // Add escape caharacter

Or more briefly

ss << "hello" << i << (int)i << esc;

You can then access ss as a C string as ss.str() for something like

char output [256];
memcpy(output,ss.str());

If you want to put a ascii version of an int - what you usually used
sprintf() type stuff for in C you can do

std::stringstream ss;
int ii;

ss << i and it is like you sent i to std::cout in that it gets turned
into ASCII.



>
> But at least I can keep doing stuff like that as long as I want... And
> with
> a good C++ compiler, that will run pretty fast. Of course, something
has
> to
> be done about the temp variables as I can't for the life of me seem to
> find
> a method that clears out a basic_stringstream to allow it to be
reused...


Easiest way is destruct and construct.

       for (;;)
       {
               std::stringstream ss;        // all constructed clean and
empty new

               // do new stuff to go to ss
               ss << goobledyGook();

               // now do something with the completed buffer

               doneWith(ss.str());

       } // when flow gets here the ss is destructed and goes away
}

This all make more sense?

>
> But this can NOT be right, right? The C++ standard library must have
made
> it
> easier to append text, binary values, and decimal conversions of
values to
> a
> contiguous array of characters? It just can NOT be that Visual Basic
is
> better for this...
>
> P.S. If someone will check my C (and other) code and post the
corrections,
> I'll put this up on the web site as an example of how to do the same
basic
> thing in VB, Perl, C and C++

I can fix the C and C++ when I really know what you meant.


-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
postmasterSTOPspamspamKILLspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\27@182432 by James Newton, Host

face picon face

> To match your C above - it makes more sense than your C++:

No doubt. <grin>

{Quote hidden}

Ah... Right, yes, 0x00 then 0x30 was intended so I should have used %d. And
%c would have made 0x00 then 0x00, yes, I see that is true and not what I
intended. Correct code would be:

char I = 0;
char s[999];
char *si = s;

si = strcpy( *si, "hello");
*si++ = i;
si += sprintf( *si, "%d", i);
*si++ = 0x1b;

And the result would be
68 65 6C 6C 6F 00 30 1b
"h "e "l "l "o  i (i)27

> stringstream (#include <sstream>) might be what you want.
>
>
>
> // replaces char s[] AND char * si
>
> std::string stream ss;

I'm assuming the space between string and stream is your spell checker and
it should have been "stringstream".

> // char I = 0 from your code?
> Const char esc = 0x1B;
> char i = 0;
>
> // A char goes through as 'binary' while an int is converted to ASCII
>
> ss << "hello";        // Add hello as text
> ss << i;                // Add I as a NULL single byte 0

Oh? That works? Cool! Why does that work? If "i" had been 123 it would have
appended 0x7B?

> ss << (int)i;        // Add I as an ASCII string or 0x30

And if "i" had been 123 then it would have appended 0x30,0x31,0x32?

{Quote hidden}

See, that won't work. I will have to find the length of ss, then allocate a
char array on the heap, memcpy it and then return the char array, I guess.

> If you want to put a ascii version of an int - what you usually used
> sprintf() type stuff for in C you can do
>
> std::stringstream ss;
> int ii;
>
> ss << i and it is like you sent i to std::cout in that it
> gets turned into ASCII.

But this is only because the type is int rather than char? That is confusing
as all get out. So the << appends the binary value if the types match and
the decimal value if they don't? That is NOWHERE in my documentation. Time
to start a web page...

<snip>

{Quote hidden}

I guess so. Isn't the point of an object oriented language to enable the
objects to know what to do with themselves? Why isn't it ss.doneWith? But
that isn't a question for you, rather a question for whoever writes the C++
language.

It's a strange world. But then I say that about Perl as well. And I'm sure
others feel the same about C or asm.

Thanks again.

---
James Newton: PICList webmaster/Admin
@spam@jamesnewton.....spamspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



2006\02\27@210731 by Gerhard Fiedler

picon face
James Newton, Host wrote:

> In VB or something like that I could just do
>
> i = 0
> S = s & "hello" & Chr(i) & CStr(i) & Chr(27)
> REM the CStr probably isn't required, but makes it more clear.
>
> And I would have a buffer with the following hex values in it:
>  68 65 6C 6C 6F 00 30 1b
>  "h "e "l "l "o  i (i)27
>
> In Perl, I would use the pack function: [...]

Sounds like you wanted the string and stringstream classes...

Gerhard

2006\02\27@212130 by James Newton, Host

face picon face
Gerhard Fiedler Sent: 2006 Feb 27, Mon 18:07
>
> James Newton, Host wrote:
>
> > In VB or something like that I could just do
> >
> > i = 0
> > S = s & "hello" & Chr(i) & CStr(i) & Chr(27) REM the CStr probably
> > isn't required, but makes it more clear.
> >
> > And I would have a buffer with the following hex values in it:
> >  68 65 6C 6C 6F 00 30 1b
> >  "h "e "l "l "o  i (i)27
> >
> > In Perl, I would use the pack function: [...]
>
> Sounds like you wanted the string and stringstream classes...

As I understand it, string and stringstream do not actually maintain a
contigous area in memory where their content is accessable. E.g. you can't
point to one and read out bytes that contain what the string in basic or the
result of the pack function returns.

You then have to convert them to such an array of characters by calling
their .str() function to make an actual string from the result.

But, yes, it sounds like that is as close as it gets.

---
James Newton: PICList webmaster/Admin
spamjamesnewton.....spam.....piclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2006\02\27@222124 by Gerhard Fiedler

picon face
James Newton, Host wrote:

> As I understand it, string and stringstream do not actually maintain a
> contigous area in memory where their content is accessable. E.g. you
> can't point to one and read out bytes that contain what the string in
> basic or the result of the pack function returns.

If you return a string object (or a pointer to one), you can access
individual elements. Like with .operator[], or with .data(). I never had to
look into that in detail, but it seems to me, from the description of
data(), that the string data is contiguous.

> You then have to convert them to such an array of characters by calling
> their .str() function to make an actual string from the result.

Isn't that pretty much the same as the other languages you mentioned? (I'd
look into .data() for this.)

Gerhard

2006\02\28@103740 by William Killian

flavicon
face


> -----Original Message-----
> From: piclist-bounces.....spammit.edu [KILLspampiclist-bouncesspam_OUTspammit.edu] On
Behalf
> Of James Newton, Host
> Sent: Monday, February 27, 2006 6:24 PM
> To: 'Microcontroller discussion list - Public.'
> Subject: RE: [EE] selecting the right C++ STD library memory buffer
>
[...]
> > Did you mean to put a 0x00 followed by 0x30?  Or 0 as binary
> > and 0 as ACII?  Lets assume you did.  You should have used a
> > %d not %c for that
>
> Ah... Right, yes, 0x00 then 0x30 was intended so I should have used
%d.

Or %u if unsigned.

> And
> %c would have made 0x00 then 0x00, yes, I see that is true and not
what I
{Quote hidden}

and
> it should have been "stringstream".

Yes.  Me or Outlook.  Yeah I'll blame Outlook. <g>

>
> > // char I = 0 from your code?
> > Const char esc = 0x1B;
> > char i = 0;
> >
> > // A char goes through as 'binary' while an int is converted to
ASCII
> >
> > ss << "hello";        // Add hello as text
> > ss << i;                // Add I as a NULL single byte 0
>
> Oh? That works? Cool! Why does that work? If "i" had been 123 it would
> have
> appended 0x7B?

That is the stream part of stringstream.  It is a string builder that
works like an ostream.  Along the lines of how sprintf relates to
fprintf.


> > ss << (int)i;        // Add I as an ASCII string or 0x30
>
> And if "i" had been 123 then it would have appended 0x30,0x31,0x32?

Yes.

{Quote hidden}

allocate
> a
> char array on the heap, memcpy it and then return the char array, I
guess.

Do you have a function of some type that needs a char[]?  Can you just
save away the stringstream and later use the .str()?  

Could you save the string stream instead of an array of char?

Stringstream * func()
{
 stringstream * pSS = new stringstream();

 // Do your stuff
 *pss << "hello";

 return pss;
}

And return or save away the string stream instead of a char array.

{Quote hidden}

It is exactly the %c versus %d thing in a different set of functions.  A
char is by default treated as a %c type operation and an int like a %d
operation.

> So the << appends the binary value if the types match and
> the decimal value if they don't? That is NOWHERE in my documentation.
Time
> to start a web page...
>
> <snip>

Huge books are written on stl.

<sarcasm>
And Microsoft has always had documentation of the same quality as the
rest of their products -
</sarcasm>
So yeah if its in there is is darned hard to find.

> > > find a method that clears out a basic_stringstream to allow it to
be
{Quote hidden}

the
> objects to know what to do with themselves? Why isn't it ss.doneWith?
But
> that isn't a question for you, rather a question for whoever writes
the
> C++
> language.

I'm not real fond of what they did to C++ since the early versions.

The idea is that you create them when you need them and destroy them
when done.  The equivalent of malloc and free.   In C the style would be
to allocate a buffer use it, free it.  When you need to start over you
start with a fresh malloc.


> It's a strange world. But then I say that about Perl as well. And I'm
sure
> others feel the same about C or asm.

It's a mindset.  You get used to a tool by learning its idioms.
Although I have written object oriented assembly.  That was unusual to
many old assembly hacks.

>
> Thanks again.

You're welcome.  No problem.  Returning the favor of people helping me.




-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
spam_OUTpostmasterspamTakeThisOuTvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\28@105143 by William Killian

flavicon
face
> -----Original Message-----
> From: .....piclist-bounces.....spamRemoveMEmit.edu [spam_OUTpiclist-bouncesTakeThisOuTspamEraseMEmit.edu] On
Behalf
{Quote hidden}

can't
> point to one and read out bytes that contain what the string in basic
or
> the
> result of the pack function returns.

Actually they do.  That is what std::string::c_str() and
std::stringstream::str() do.  You read out the bytes contained by
calling those methods.

But in the OO world the implementation hiding is considered a good
thing.

You can get to individual elements of std::string easily with substr(),
insert characters in the middle with insert().

> You then have to convert them to such an array of characters by
calling
> their .str() function to make an actual string from the result.

That is reading out the bytes.  No 'conversion' per se, just limited
access to the char[] buffer inside.

> But, yes, it sounds like that is as close as it gets.

They are weird until you get used to them.  Now that I am I still think
I would have doen them differently (Bill's first law of software
engineering: All other programmers are idiots.  Tongue is extremely
firmly in cheek when I say that.)

Play with them and get used to them.  I/O formatting is weird but it
works.  Printf is still better in many cases though -  and probably more
efficient at a cost of making you do a lot of work and probably end up
with something not much more efficient at the end.


-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
EraseMEpostmasterspamBeGonespamKILLspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\28@110359 by Alan B. Pearce

face picon face
>You get used to a tool by learning its idioms.
>Although I have written object oriented assembly.

Any pointers on where to get info on doing this? I tried to get the info
from Microsoft that was presented on this at last years Masters, without
success.

The nearest I have come to OOP in assembler is by using linkable modules.

2006\02\28@112924 by William Killian

flavicon
face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesspamBeGonespamspammit.edu [@spam@piclist-bouncesspamspammit.edu] On
Behalf
> Of Alan B. Pearce
> Sent: Tuesday, February 28, 2006 11:04 AM
> To: Microcontroller discussion list - Public.
> Subject: Re: [EE] selecting the right C++ STD library memory buffer
>
> >You get used to a tool by learning its idioms.
> >Although I have written object oriented assembly.
>
> Any pointers on where to get info on doing this? I tried to get the
info
> from Microsoft that was presented on this at last years Masters,
without
> success.
>
> The nearest I have come to OOP in assembler is by using linkable
modules.

Hand rolled in 68k assembler.  I did all the class equivalent stuff
myself.  It was not the clean syntax of an object oriented language.  

OO is a mindset not a language.  Some languages just make it easier and
some (old BASIC for example) make it really really hard.




-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
TakeThisOuTpostmasterKILLspamspam@spam@vgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\28@114440 by Alan B. Pearce

face picon face
>Hand rolled in 68k assembler.  I did all the
>class equivalent stuff myself.  It was not
>the clean syntax of an object oriented language.

OK, I just figured that maybe you had some specific methodology that helped.

>OO is a mindset not a language.

Yeah, appreciate that. I did find that using linkable modules (in this case
built through Olins environment) helped the OOP mindset with assembler as it
was possible to maintain a certain degree of "hidden detail" because of the
modules and the PIC banking (it was on a 16F876).

2006\02\28@190047 by Peter

picon face

On Tue, 28 Feb 2006, Alan B. Pearce wrote:

>> You get used to a tool by learning its idioms.
>> Although I have written object oriented assembly.
>
> Any pointers on where to get info on doing this? I tried to get the info
> from Microsoft that was presented on this at last years Masters, without
> success.
>
> The nearest I have come to OOP in assembler is by using linkable modules.

I think that you can use the usual 'system call interface' paradigm. All
data is private to a set of subroutines, which form an object. There is
a single entry point and you select the function (method) using a
parameter. Inheritance is by forwarding calls to an inherited object.

Peter


'[EE] selecting the right C++ STD library memory bu'
2006\03\01@101624 by William Killian
flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesRemoveMEspammit.edu [KILLspampiclist-bouncesspamTakeThisOuTmit.edu] On
Behalf
{Quote hidden}

info
> > from Microsoft that was presented on this at last years Masters,
without
> > success.
> >
> > The nearest I have come to OOP in assembler is by using linkable
> modules.
>
> I think that you can use the usual 'system call interface' paradigm.
All
> data is private to a set of subroutines, which form an object. There
is
> a single entry point and you select the function (method) using a
> parameter. Inheritance is by forwarding calls to an inherited object.
>
> Peter

What I've done in the past is use jump/call tables to simulate the
hidden vtable of C++.  Its not pure OOP so the academic programmers
freak out (same way they freak out when I call C++ Templates a Macro
facility).  You have to make your own 'this' with a parameter/register
pointing to a data 'structure'.  That is a lot like the
fputX/fprintX/sprintf type C functions where thepointer to FILE is the
equivalent of this really.  I use this approach in any language such as
C or assembler that doesn't directly support objects.  I try to make a
similar set of function/subroutines that use a similar API with
programming by difference.  I make generic routines for most integer
types for example with specialized ones called for some that are
effectively derived types.  None of this is new with C++ or even pure OO
languages from the '90s since all were inspired by Simula '67.

Even the new buzzwords of generic programming and design patterns are
really just old ideas we've been doing 'forever' just with fancy names.





-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
TakeThisOuTpostmasterspamspam_OUTvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

'[EE] I am sooo stupid with C++ std...'
2006\03\23@221538 by James Newtons Massmind

face picon face
Why doesn't this work? Two days of reading everything I can find, pounding
my head against the wall and I can't make heads or tails of it. Could have
had it done in an hour if I was using C (malloc and atoi and all that rot)
but I wanted to try and use C++ ideas and standard library stuff. I thought
I understood C++ to some degree. Objects, information hiding, inheritance,
operator overloading... I got all that. But this standard library stuff is
just... Like a whole 'nother language.

Here is as close as I can get to something that almost compiles, but it
doesn't. "delete can not convert from tRePosition to void *"


//move any element in one of the src areas to the associated dst area

struct tRePosition {
       struct {
               int x1,x2;
               int y1,y2;
               } src;
       struct {
               int x;
               int y;
               } dst;
       };

struct delete_RePosition : std::unary_function<tRePosition,void>{
   void operator()(tRePosition p) const {
       delete [] p;
               }
       };

std::vector<tRePosition> RePositions;

std::ifstream fin("D:\\input.txt");
//file with some number of lines each with 6 integers seperated by spaces
while (!fin.eof()) {
       tRePosition *RePosition = new tRePosition;
       fin >> RePosition->src.x1;
       fin >> RePosition->src.y1;
       fin >> RePosition->src.x2;
       fin >> RePosition->src.y2;
       fin >> RePosition->dst.x;
       fin >> RePosition->dst.y;
       RePositions.push_back(*RePosition);
       }
/*        
 Do stuff with the RePosition 's in RePositions. For example: Given an
element with an X and Y position (PosX, PosY)
*/
for(i=RePositions.size(); i>0; i--) {
/*
This should be a function so for_each could be used, but I cant even get
the delete function to work in for_each...
*/
       if ( PosX >= RePositions[i].src.x1
         && PosX <= RePositions[i].src.x2
         && PosY >= RePositions[i].src.y1
         && PosY <= RePositions[i].src.y2 ) {
//...

               }
       }


// Then...

std::for_each(RePositions.begin(), RePositions.end(), delete_RePosition() );

---
James Newton, massmind.org Knowledge Archiver
RemoveMEjamesspamspamSTOPspammassmind.org 1-619-652-0593 fax:1-208-279-8767
http://www.massmind.org Saving what YOU know.

2006\03\23@225906 by Matthew Miller

flavicon
face
Hi James. I think I see some problems. I've interspersed my comments in your
code...

On Thu, Mar 23, 2006 at 07:15:35PM -0800, James Newtons Massmind wrote:
{Quote hidden}

Your declaring a vector of tRePosition structs. To later be able to call
delete on the elements you must use the type *tRePosition for the
vector. You can't call delete on the object itself, but only on a pointer to
it. Also, since you're not deleting an array of tRePosition objects you
shouldn't call delete with [].

{Quote hidden}

I don't see anything else that might be wrong. The compiler error you
reported doesn't seem to match up with what I see here, but I've seen
compilers give incomprehensible errors and warnings before.

Take care.

Matthew

--
"It is a miracle that curiosity survives formal education"
    -- Albert Einstein

2006\03\24@171728 by James Newtons Massmind

face picon face
Matthew Miller Sent: 2006 Mar 23, Thu 19:59
> Hi James. I think I see some problems. I've interspersed my
> comments in your code...
>
> On Thu, Mar 23, 2006 at 07:15:35PM -0800, James Newtons
> Massmind wrote:
<SNIP>
> >
> > std::vector<tRePosition> RePositions;
>
> Your declaring a vector of tRePosition structs. To later be
> able to call delete on the elements you must use the type
> *tRePosition for the vector. You can't call delete on the
> object itself, but only on a pointer to it. Also, since
> you're not deleting an array of tRePosition objects you
> shouldn't call delete with [].

Oh my... Ok, so I've changed it to

std::vector<tRePosition *> RePositions;

And taken out the [] and all seems to be well.

THANK YOU!

---
James.


2006\03\24@171836 by Gerhard Fiedler

picon face
Matthew Miller wrote:

> On Thu, Mar 23, 2006 at 07:15:35PM -0800, James Newtons Massmind wrote:
>>
>> struct tRePosition {
>>        struct {
>>                int x1,x2;
>>                int y1,y2;
>>                } src;
>>        struct {
>>                int x;
>>                int y;
>>                } dst;
>>        };
>>
>> struct delete_RePosition : std::unary_function<tRePosition,void>{
>>     void operator()(tRePosition p) const {
>>         delete [] p;
>>                }
>>        };

James, when you cite an error message plus code, it helps to inform the
offending line :)

> The compiler error you reported doesn't seem to match up with what I see
> here, but I've seen compilers give incomprehensible errors and warnings
> before.

I may miss something (it's been some time with C++ :), but for me it does
match up (and matches your explanation of the problem).

It seems to be the delete operator above. It calls an operator delete
function that has as sole argument a void pointer. This (and the general
functionality of delete) requires that what you want to delete has to be a
pointer -- preferably with a content that came from a previous call to new.

p above is not a pointer, it is a struct tRePosition. p in "delete [] p"
can't be converted into a void*, because it is a tRePosition -- which is
what your error message seems to complain about. It probably would not
complain if p were tRePosition*.

Gerhard

2006\03\24@235921 by Matthew Miller

flavicon
face
On Fri, Mar 24, 2006 at 02:17:22PM -0800, James Newtons Massmind wrote:
>
> Oh my... Ok, so I've changed it to
>
> std::vector<tRePosition *> RePositions;
>
> And taken out the [] and all seems to be well.
>
> THANK YOU!

I'm glad I could help. Take care.

Matthew

--
...We shouldn't test people for drugs, we should test them for
stupidity, ignorance, greed and love of power. -- P.J. O'Rourke


'[PIC] MPLAB MC18 stdlib question ultoa function'
2006\06\20@161221 by Phillip
picon face
part 1 6513 bytes content-type:multipart/related; (decoded 7bit)

This is a multi-part message in MIME format.

------=_NextPart_000_0016_01C69473.8A623680
Content-Type: text/plain;
       charset="us-ascii"
Content-Transfer-Encoding: 7bit





Hi all

I'm having unwanted behavior from the code below  in my current 18F6520
project



current_brightness is always a value from 0 to 1000 decimal.

But every so often holder winds up with garbage that is nothing resembling
the value I'm passing in current_brightness



void post_bright(unsigned int current_brightness)

{

   unsigned long x;
//debug

   char holder[6];                                                  

  if((current_brightness > 1000) || (current_brightness < 20))
//debug

   x = x +1;                                   //debug - spot for break
point                                     if I put a break point here the
debugger never reaches this point so I believe current_brightness stays
between 0 to1000

   ultoa((unsigned long)current_brightness,holder);

  if (strlen(holder) > 4)
//debug

     x = x +1;
//debug - spot for break point              when I put a break point here I
sometimes get more than 4 characters in holder e.g. "4287?2" when
current_brightness is 1000 or 0x03E8





When this occurs I'm sending characters to the serial port by holding the
key down on a terminal emulator (my baud rate is only 9600 but still the
chars a coming as fast as my terminal can send them)

If the character is valid (e.g. an up arrow is a valid character )  My ISR
calls a function (push_button_event) that pushes a command into a circular
buffer..so a user hitting an up arrow key on a terminal is the same as a
user hitting a up hardware key on the front panel.



void push_button_event(unsigned char cmd_in)

{



*button_head = cmd_in;



if (button_head == &BUTTON_BUFF[BUTTON_BUFF_LENGTH -1])
//if the pointer reaches the end of the buffer reset to the start of the
buffer to store commands

  button_head = (unsigned char*) &BUTTON_BUFF;
//it is theoretically possible to over write previous commands if but if
you've buffered up BUTTON_BUFF_LENGTH commands        

else
//without processing them then something is likely very wrong

  button_head++;

}





I think that what might be happening is that the called function does not
return before the next character/ interrupt arrives so the push_button_event
is called before the last call has time to finish and so the stack is grows
occasionally reaching a point where the ultoa function  is trying to use a
stack where there is no room left for its correct operation so I get
nonsense.





Seems to me I could disable interrupts during the pushbutton function or I
could increase my stack size.





In my linker script the stack is specified by this line (me thinks)

STACK SIZE=0x100 RAM=gpr6



Maybe I should bo both?

Or maybe there is a problem else where

Thanks in advance to the usual smart people.



Phillip

Things should be as simple as possible but no simpler







Phillip Coiner

CTO, GPS Source, Inc.





Your source for quality GNSS Networking Solutions and Design Services, Now!




------=_NextPart_000_0016_01C69473.8A623680
Content-Type: image/jpeg;
       name="image001.jpg"
Content-Transfer-Encoding: base64
Content-ID: <image001.jpg@01C69473.2480F9A0>

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCAA9AHIBAREA/8QAHwAAAQUBAQEB
AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh
ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ
WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZaKKKKKKKRmVFLMQqg
ZJJwAKoWmvaPqEcslnqtncJCcSNHOrBPrg8VnXnjPT4XMVmkl9L2EQ4/P/Cs6fUvF2oKfs1g1pGe
mFAb82/wrndUXWLeULqb3IZ+R5khIP05xW/4DtrrzZ7os62u3YFJ4Zs9ce39a7WiiiikyM4yM+lL
RUF3e21jF5t1MsS9snk/Qd65bxUuseLPDd9pej2T26XEe0XFy3l7xkHAHXnGMn1rgfhn8MtatPEM
l5r9ibazijZPLeQZmY9PunoOua9lht7LT1EcMUNuDwAAFzVgkBSxIAAzkniuWu7N/FupxuN0emW2
QJOhmPfb7cda6aCCK1gSCCMRxoMKq9AKkoorkvHnj+x8E2S7k+0384Jgtgccf3mPZf514nc+LPHf
jm/a3tbi9lLc/ZrEFEUe+3t7salb4YfEBIxcf2dMW64F0hcf+PV6h8K7XWNE8OXdx4nuruJnn2Qw
XjsTGqjsD6knp6CuG+Mfim+n8Tw2VpcXlpbwWy5j3tHvZiTuKg+mOtZEXw68d3WmQ6xDDLMjxCaM
rdAyFSMggZznHbrWr8O/ifrOna5baTrV1LeWNxIISZyTJAxOAQx5xnqDXQfFf4mX+l6i/h7Qpvs8
kag3Vyv3wSMhV9OMZPXmuFs/h9438QWS6sbaV45hvSS5uAHkB6EBjnmvQPhV4N1+xn1D/hIje29s
gVEs5JSY5SeS2AcEDAHHqa9YVVVQqgKoGAAMAUtFFIzKiM7HCqMk+gr5S8Ratd+MfGE93ku93cCO
3Q/wrnCL+WP1r6R8M+HdN8GeHUtLdUQRR77mfHMjAfMxP549BXO3Hxj8JFhHbaiy56yyW0hVfoMZ
J/Kt/wAL6roviS3fU9NuJL5o38tp5oypDYBwoIGBz2r588fXY1j4jao4kG1rvyFYnAAXCf0r3u+8
beFvDGipv1e1mFvCEjht5Vkd9owAAD+prwDwzZXPir4gW3kxEG4vftEoXpGm/cx/AVe+K2lzWXjq
+uifMtr1/NhlXlTwNy59QePyrvfh98W9Ongt9L8REWt1Goiiuz/qmAGBn+4ffp9K9bVldQykMpGQ
QcgiloooqtqMbzabdRRffeF1X6lTivlDw5dRab4o027uRiO3u43kzxgBhmvqbUNMXWtMuLae4YR3
ULIphPChhjI9Tz1NfO/xJ8Iab4M1i10+wu7i4aWDzZDNt+XJIAGAPQ1678LIBonwthvJBjes1230
5x+iivCdC0e78YeKI9PhkVJ72R3Mj5IXgsScfSu1j+C10t39nl1u3mlB5itImkYfUnAX8a9N8IfD
vTvDFqyjLySgeac8v7M3cewwPrXQax4f0rXtNOnalZRT238KkY2H1UjofpXz38S/ACeCb+3e0uWm
sbzd5Qk++hXGQfXqOa9P+COq3WoeCpLe5cutlcGKJj1CbQwH4EmvRqKKKzJtTe5vGsNN2vKn+umP
KQ/4t7fnXjvxH+E+oW2oSav4fgkvbacl5oEGZI37kAdQTzx0+lcxpXxC8aeF7ddOiu5UiiG1YLqE
MUHoNwyB7VTvx4r8daqdQmsrq+uGQLvjt9qKo6DgYAr2LxNq9no3wvm0awL3FxHYJanyFLBCQFOS
OO5rgvg34blv/FFxPdC4t4ra2PKgoWLEDGfpmvfra1t7OEQ20KRRj+FRisfxtd6lZ+ENRl0m2muL
0xFIlhGWXdwWA68Ak8eleDWPxQ8b6HH9ke/d9nAW8hDsv4kZ/Oqs7eMfiZq8TvFPfSD5EKx7IYR3
56D69a+gPBHhaPwh4Zg0tXEk2TJPIOjSHrj2HAH0roKKK4/xT4pMZfT9Okw/KzSj+H/ZHv71c8Na
lo9pokMQvIYpcbpQ7YYueuc1bufFmi2wObwSn+7Epb/61Uf7e1PVjjSdH+TtPdcKPeny+G769tpG
1PU2nl2Hy4V+SFWxxkDqM0/wXtTR5LdhOlzbTGK6jmZW2SgAnaVGCpyCPrUusT3FzrVno8V49lFL
BLcTzRkCQqhUBVJHHLZJ9B71J4Vu7i90GKe4nNx+9lWOdgAZY1kYI5xxyoBz361R1fW57O+1t458
R6dpiOsfHMzl9p/8dUfjW3a2m6wtkvlS4nSJRI7oCWYAZP51ydnqOp3fjRre3muIbdbuRVVigt3g
iVVdVX72/wAw5zxx7V1mq3p03Sby+EfmG2geUJ/e2qTj9KqaDaXEdst3d6pNez3MSu4LDykJGfkU
Dgdu+cVW8XXl7b2dlb6cZPtN3eJGBE6o5QAu4DNwPlU81PHoUjRqW1jVVYgZH2hTg/8AfNef3unm
1v5LYzb9r43FcZ5+tdDpngmG7iWae9faf4UQD9STXRWPhrSdPIaK0V3H8cvzH9a1egxUc8EVzA8E
8ayRSKVdGGQwPUGo7KxtNOtxb2VvHbxAk7I1wMnqfrTL/StP1VEXULKG5EZyglQNt9cVZRFjRURQ
qqMKqjAA9Kq3Gkabd3kd5cWMEtxFgJK8YLDByOfY81cqumn2cbxulrErRO8iEIMqz53Ee5yc/Wp2
UMpVgCCMEHvVWw0rT9KR0sLOG2WQ5YRIFBpNQ0nT9WjSPUbOG6SNtyCVAwU4xkVajjSKNY41CIgC
qo6ADoK//9k=

------=_NextPart_000_0016_01C69473.8A623680--



part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)


'[PIC] is there an error in the 18F2525 POSTDEC0 lo'
2007\12\25@205623 by Pat O'Toole
flavicon
face
Hello.

I'm been debugging this routine...

clearram   lfsr    FSR0,h'F7F'                                  ; point to the highest user ram position for 18F2525
eraseram  clrf    POSTDEC0,1                                   ; erase memory
              tstfsz  FSR0L,ACCESS
                 bra   eraseram
              tstfsz  FSR0H,ACCESS
                 bra   eraseram

it puts the chip into an infinate loop....
and does the same when I run the simulator on the MPLAB-IDE...
for some reason the FSR0 register never changes to a lower value.

if I change the code to start at address 0 and do a POSTINC0
that does seem to work..

Just wondering if this is a known hardward defect or am I missing something??

Pat

2007\12\25@225937 by Spehro Pefhany

picon face
At 08:56 PM 12/25/2007, you wrote:
>Hello.
>
>I'm been debugging this routine...
>
>clearram   lfsr    FSR0,h'F7F'                                  ;
>point to the highest user ram position for 18F2525
>eraseram  clrf    POSTDEC0,1                                   ; erase memory
                            ^^^
try getting rid of this......

{Quote hidden}

>


'[EE] IPC J-Std Soldering'
2009\03\26@132152 by Joseph Bento
face
flavicon
face
Hey all,

I have recently found myself among the unemployed.  I reported to work  
on March 19, and upper management and the CEO were in the tech  
center.  They called an all-hands meeting around 8:30 after everyone  
had arrived, and proceeded to tell the 15 of us that the tech center  
was being terminated along with our jobs.

I worked for this company for nearly three years, assembling and  
troubleshooting engineering prototypes.  I am skilled at SMT soldering  
and rework down to about 0.4mm, but do not hold a J-Std  
certification.  In the past, proof or demonstration of my skills was  
sufficient, as was my nearly 10 years of military electronics  
experience.  Apparently no longer - the labor market is so voltile,  
and the job descriptions are far more exacting.  Potential employers  
won't even make a consideration unless you are a perfect match for  
every point in the job description.

How does one obtain their J-Std or other certifications unless their  
employer obtains the training?  I haven't been able to find many  
references that include individual career development, nor have I  
found anything that looks remotely affordable for an unemployed  
technician.

Thanks

Joe

2009\03\26@134623 by Carl Denk

flavicon
face
Where are you located?, Willing to relocate? The only thing here in
Northern Ohio is
http://www.inservco.com/

I'm not in the business, but know they were busy and have expanded in
recent time.
They do board assembly mainly for the medical, but others, and handle
testing and repairs on many of the boards for the client. From what I
hear they treat their employees vary good.
Joseph Bento wrote:
{Quote hidden}

2009\03\26@140129 by Joseph Bento

face
flavicon
face

On Mar 26, 2009, at 11:46 AM, Carl Denk wrote:

> Where are you located?, Willing to relocate? The only thing here in
> Northern Ohio is
> http://www.inservco.com/

I'm in the Salt Lake City, UT area.  Job listings are rather sparse,  
and salaries are dropping. Relocation is not an option at this time -  
too many family related commitments to the area.

Joe


2009\03\26@145912 by Carl Denk

flavicon
face
Understand family. 40 years ago, I almost took a job in Pocatello, ID.
Things are pretty bad around here, and look for things to get a lot
worst, and I don't know what that means. :(

Joseph Bento wrote:
{Quote hidden}

2009\03\26@150019 by cdb

flavicon
face
Have you guggled for IP610 training?

In the past I have seen some trade institutions run courses, but they
are expensive, and they normally only run them when they have a
largish attendance.

Colin
--
cdb, .....colinEraseMEspambtech-online.co.uk on 27/03/2009

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359







2009\03\29@201922 by Richard Seriani

picon face

----- Original Message -----
From: "Joseph Bento" <spamBeGonejosephspamRemoveMEkirtland.com>
To: "Microcontroller discussion list - Public." <.....piclistEraseMEspammit.edu>
Sent: Thursday, March 26, 2009 1:21 PM
Subject: [EE] IPC J-Std Soldering


{Quote hidden}

Joe,

Have you checked IPC.org web site for info on training?
If not, check under the Knowledge tab, then Training and Certification.
Several places around the country provide training.

Ideally, try getting with a company that will test your skills, then pay for
you to receive the training. Check out government contractors, particularly.
If you are good enough and demonstrate the right attitude, they may also pay
for you to become a trainer.

Good Luck.

Richard



'[TECH] Prestdigitation, now you see it, now you do'
2011\02\01@150542 by cdb
flavicon
face
Calcite has been shown to naturally be a 'birefringent' material as it naturally splits light into opposite polarisations therefore providing a cloaking effect.

This is apparently much cheaper than making artificial materials to do the same job.

http://www.bbc.co.uk/news/science-environment-12338447

Be rich and start investing in calcite now!

Colin
--
cdb,   3/07/2009
--




spamcolinspam_OUTspam@spam@btech-online.co.uk


'[EE] Suggestions regarding IPCJ-STD-001 training'
2012\08\30@225701 by Dwayne Reid
flavicon
face
Good day to all.

One of our customers is asking us to have some of our assemblers trained to IPCJ-STD-001 standards.  We've been quoted Can $2000 per person by a local company and I'm trying to get an idea of that cost is in line with industry norms.

We've mostly been working to the Martin Marietta Workmanship standards from a decade or two ago but this is an internal in-house affair, not certified by any outside authority.

Any thoughts or suggestions gratefully accepted.

Many thanks!

dwayne

-- Dwayne Reid   <spamdwayner@spam@spamSTOPspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

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