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

Truncated match.
PICList Thread
'C-compilers for PIC'
1997\06\09@024534 by Havard Torring

flavicon
face
Does anyone know if there exists any WORKING C-compilers for PIC
microcontrollers.  I have been using MPLAB-C for a while, and it is simply
the WORST C-compiler I have ever tried.  The compiler crashes if you do not
carefully insert spaces and comments at all critical places in your code.
If you are lucky enough to be able to run the compilator on your code, you
can be quite shure that the code it produces is wrong.

So, is this the only option out there??

HŒvard
------------------------------------------------
HŒvard T¿rring
spam_OUThtTakeThisOuTspamneo.no    .....xplisitKILLspamspam@spam@neo.no    simplisitspamKILLspamneo.no
Norsk Elektro Optikk A/S       Tel: +47 67974700
PoBox 384                      Fax: +47 67974900
1471 SkŒrer
Norway

1997\06\09@032346 by Lars Johansson 6018384

flavicon
face
ÈDoes anyone know if there exists any WORKING C-compilers for PIC
Èmicrocontrollers.  I have been using MPLAB-C for a while, and it is simply
Èthe WORST C-compiler I have ever tried.  The compiler crashes if you do not
Ècarefully insert spaces and comments at all critical places in your code.
ÈIf you are lucky enough to be able to run the compilator on your code, you
Ècan be quite shure that the code it produces is wrong.
È
ÈSo, is this the only option out there??
È
ÈHŒvard

Hi HŒvard!
I couldn't agree more...
I have written a C-program and in one
line am I doing this calculation:
.
char nr_overflow=0;
char timer_value=0;
unsigned long period=0;
char x =1;
.
.
period=(timer_value+nr_overflow*256)/x;
.
.
When I multiplie the variabel nr_overflow with 256 everything works fine.

BUT, if I do the same thing but multiplie nr_overflow with 255, nothing
works. The value that period get, is totally wrong!!!!

You can find a DOS c-compiler at: http://www.htsoft.com
I haven't tried this one, so I cant say if it's good or bad.

//Lars Johansson, Stockholm Sweden

1997\06\09@043209 by Aschwin Gopalan

flavicon
face
Hi!

Havard Torring <.....htKILLspamspam.....neo.no> writes:

{Quote hidden}

I can't comment on MPLAB-C, since I can't afford it. I am using
CCS PCM here ($99) and just recently tried HiTech-Softs beta 2 which
you can get for free from their homepage

   http://www.htsoft.com

Here my comments:

What I like about CCS PCM:
- It has a very rich set of builtin functions which make your
 life easier, (rs232, printf, i2c ...)
- It is very much ANSI C
- It now has floating point and signed math!
- It can efficiently handle bit variables
- Its really not expensive
- Integrates nicely with MPLAB

What I don't like about CCS PCM:
- It seems to generate incorrect code sometimes (at least the older
 version I used before)
- It can only do the midrange chips (though there are a lot of them)
 You would have to buy another compiler for the same price to do
 the low-end chips and they don't have one (yet) for the 17C...
- long int is only 16 bits. Quite often I would need 32 bit signed ints...

What I like about HiTech-Softs Compiler

- The beta is free!
- It does IMHO a really good job at optimizing. If you do bitwise and
 or or to set or reset a single bit, it uses the bit set/clear opcodes
- it has 32 bit, 16 bit and 8 bit singed and unsigned ints and 24 and 32 bit
 floats
- comes with a big library, including sin,cos and such things
- works with the low-end and the mid-range chips, will work with
 the high end chips, too

What I dont like about HiTech-Softs Compiler

- beta will expire in November, the real thing will be quite too expensive
 for me, so I better don't get used to it :-(
- Has some code generation bugs (but its a beta!)
- Has not (yet) quite so many special functions to deal with pic periphery
- does not integrate with mplab as good as pcm

Well, that are my DM0.02 worth.
Please correct me wherever I am wrong.

Finally, I must say that after enjoying assembler programming a lot when
I started picin', just because it reminded me of the good old days of
sinclair spectrum hacking, I am happy to be able to do larger projects
in C. Both of the above compilers help me a lot doing that.

Bye,

Aki

1997\06\09@044454 by tjaart

flavicon
face
Aschwin Gopalan wrote:
>
> Hi!
>
> Havard Torring <EraseMEhtspam_OUTspamTakeThisOuTneo.no> writes:
>
> > Does anyone know if there exists any WORKING C-compilers for PIC
> > microcontrollers.  I have been using MPLAB-C for a while, and it is simply
> > the WORST C-compiler I have ever tried.  The compiler crashes if you do not
> > carefully insert spaces and comments at all critical places in your code.
> > If you are lucky enough to be able to run the compilator on your code, you
> > can be quite shure that the code it produces is wrong.
> >
> > So, is this the only option out there??
> >

Here's my two cents :
Before you buy *anything*, find out what the turnaround time for
a bugfix is. There is nothing more expensive than waiting for bugfixes
that never come. I think you have probably noticed this as a MPLAB-C
user (as I have).

--
Friendly Regards

Tjaart van der Walt
tjaartspamspam_OUTwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             WASP International  http://wasp.co.za           |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8973  |
|_____________________________________________________________|

1997\06\09@090845 by trogers

flavicon
face
Havard Torring wrote:
>
> Does anyone know if there exists any WORKING C-compilers for PIC
> microcontrollers.  I have been using MPLAB-C for a while, and it is simply
> &etc.

I have been quite happy with the CCS stuff, although I confess that I
know how a compiler should work and always observe the output code.
You've got to realize (as some respondents do not) exactly what the job
the compiler is trying to do, and then help it, in a sense.

The CCS compilers are not supported by Microchip and the company is
small. I've come to the opinion that these are strengths. I have never
seen any of the type of problem that you described.

Tom Rogers  VP - R&D  Time Tech Inc.

1997\06\09@124110 by Eric Martens

flavicon
face
Hello Havard

|Does anyone know if there exists any WORKING C-compilers for PIC
|microcontrollers.  I have been using MPLAB-C for a while, and it is simply
|the WORST C-compiler I have ever tried.  The compiler crashes if you do not
|carefully insert spaces and comments at all critical places in your code.
|If you are lucky enough to be able to run the compilator on your code, you
|can be quite shure that the code it produces is wrong.

|So, is this the only option out there??

I have here a C compiler (freeware) i haven't had any time to test it out. The
complete
zip file is 112KB big. If you'd like i can email it to you. It looks
interesting, maybe
this is what you are looking for.

I know that a friend of mine (who does a lot of pic programming(it is his job
!!!)) has
been grumbling about the MPLAB-C program for a while now. He says the same thing
as you
do.
He always says "It's just like a small child, you have to help it to get the job
right"



Greetings Eric Martens

| | | | | | | | | | | | | | |
+-----------------------------+
|                             |
|     Eric Martens            |
|   EMAR ELectronics        +-+
|   @spam@emarKILLspamspamknoware.nl         |
| Fax: +31-(0)492-522418    +-+
| Maxer: +31-(0)660137959     |
|                             |
+-----------------------------+
| | | | | | | | | | | | | | |

1997\06\09@140356 by Rick Miller

picon face
I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
doesn't have all those nasty limitations.  Want multi-dimensional arrays?
No problem!  Want more than two arguments for a function?  No problem!
Check it out:

 http://www.execpc.com/~ccs/

Mark, the author, knows his stuff.  It's much better than any other C
compiler I've seen for the PIC.  And Cheryl (an incredibly beautiful young
woman, but married) is amazingly knowledgeable for a
secretary/receptionist.  I was extremely impressed with the compiler's
performance and exceptionally pleased with their customer support.  AND...
it's not expensive!

Rick Miller
KILLspamrdmillerKILLspamspamexecpc.com   RemoveMERick.MillerTakeThisOuTspamLinux.org

1997\06\09@220403 by Bruce Cannon

flavicon
face
My 2 cents:

Haven't tried MPLAB-C, but people have been bitching about it for a long
time now, and it costs a lot, so why bother?
The CCS compiler is cheap, and constantly being improved, and while
sometimes buggy, they really are very supportive by phone or email.  And it
integrates well with MPLAB.

----------
Bruce Cannon
Style Management Systems

Remember: electronics is changing your world...for good!

----------
{Quote hidden}

young
> woman, but married) is amazingly knowledgeable for a
> secretary/receptionist.  I was extremely impressed with the compiler's
> performance and exceptionally pleased with their customer support.
AND...
> it's not expensive!
>
> Rick Miller
> RemoveMErdmillerspamTakeThisOuTexecpc.com   Rick.MillerEraseMEspam.....Linux.org

1997\06\10@064726 by Andy Kunz

flavicon
face
At 07:46 AM 6/9/97 -0500, you wrote:
>I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
>doesn't have all those nasty limitations.  Want multi-dimensional arrays?
>No problem!  Want more than two arguments for a function?  No problem!

Want bugs?  Want a new release every day?  Want operation and definition of
"correct" changed apparently on a whim?  Don't want docs?

And that's my short list.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\06\10@100316 by ms

flavicon
face
Eric Martens wrote:

{Quote hidden}

... but I doubt whether this child will ever become an adult.

Moreover from a good and professional compiler-package I would expect
the capability of linking different C and ASM modules as well as
overlaying of local variables.

Best regards,

Marc Schmaeche

-----------------------------------------------------------------------
        ZENTRUM  FUER  ANGEWANDTE  MIKROELEKTRONIK  UND  NEUE
        TECHNOLOGIEN  DER  BAYERISCHEN  FACHHOCHSCHULEN  E.V.

 Dipl.-Ing. M.Schmaeche     Tel.:   +49 (0)9131 691145
 ZAM-Anwenderzentrum Nbg.   Fax:    +49 (0)9131 691166
 Am Weichselgarten 7        E-Mail: RemoveMEmsEraseMEspamEraseMEzam.nf.fh-nuernberg.de
 91058 Erlangen, Germany             (Ger/Eng/Spa welcome)
-----------------------------------------------------------------------

1997\06\10@190225 by Bill Collins

flavicon
face
The CCS compiler works well for me.

Bill

1997\06\10@205243 by John Payson

picon face
> At 07:46 AM 6/9/97 -0500, you wrote:
> >I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
> >doesn't have all those nasty limitations.  Want multi-dimensional arrays?
> >No problem!  Want more than two arguments for a function?  No problem!
>
> Want bugs?  Want a new release every day?  Want operation and definition of
> "correct" changed apparently on a whim?  Don't want docs?
>
> And that's my short list.

As a user of the CCS compiler, I will readily admit that the problems you
describe are indeed annoying.  On the other hand, compared with my MPLABC
experience I'd say CCS is pretty good (if you call tech support because
the compiler mis-evaluates an expression, would you rather get a response
of "Yeah, it has that problem.  We may fix that in a month or two," or
"Oops, that doesn't seem to work right.  I'll try to get it fixed by
tomorrow."

1997\06\11@005732 by tjaart

flavicon
face
John Payson wrote:
>
> > At 07:46 AM 6/9/97 -0500, you wrote:
> > >I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
> > >doesn't have all those nasty limitations.  Want multi-dimensional arrays?
> > >No problem!  Want more than two arguments for a function?  No problem!
> >
> > Want bugs?  Want a new release every day?  Want operation and definition of
> > "correct" changed apparently on a whim?  Don't want docs?
> >
> > And that's my short list.
>
> As a user of the CCS compiler, I will readily admit that the problems you
> describe are indeed annoying.  On the other hand, compared with my MPLABC
> experience I'd say CCS is pretty good (if you call tech support because
> the compiler mis-evaluates an expression, would you rather get a response
> of "Yeah, it has that problem.  We may fix that in a month or two," or
> "Oops, that doesn't seem to work right.  I'll try to get it fixed by
> tomorrow."

Exactly! I've been bitchin' & moanin' for 8 @#%$%(&*%^&*% months about
the
^&(&%$*$$^ lack of %*&$&H:\pic\pic archive 2 working interupt service routine context
saving
code. I hacked some code from the Bytecraft compiler which worked
perfectly.

About two weeks ago a Mchip engineer noted that MPLAB-C now also
features
this code (at last).

I tried Mchip's code yesterday, and it doesn't work (hahahahahahahaha).
I
had to use the hacked code for a '74 on a '64a. I am SICK, SICK, SICK of
the lack of *ANY* (null, zero, nada, zip) support on MPLAB-C. If it was
a
freeware compiler, it would have been ok, but we paid (a lot of) good
money for it.

The only upgrades we get on MPLAB-C seems to be new random error
messages.

If anybody knows of a Mchip email address where I can lodge a formal
complaint about this, please mail it to me.

--
Friendly Regards

Tjaart van der Walt
RemoveMEtjaartspam_OUTspamKILLspamwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             WASP International  http://wasp.co.za           |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8973  |
|_____________________________________________________________|

1997\06\11@011126 by Mike Smith

flavicon
face
> From: John Payson <RemoveMEsupercatTakeThisOuTspamspamMCS.NET>
> To: EraseMEPICLISTspamspamspamBeGoneMITVMA.MIT.EDU
> Subject: Re: C-compilers for PIC
> Date: Wednesday, 11 June 1997 08:52
>
> > At 07:46 AM 6/9/97 -0500, you wrote:
> > >I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
> > >doesn't have all those nasty limitations.  Want multi-dimensional
arrays?
> > >No problem!  Want more than two arguments for a function?  No problem!
> >
> > Want bugs?  Want a new release every day?  Want operation and
definition of
{Quote hidden}

Somewhere in between would be nice - like fixing it inside a week, but
running the bug-fixed version thru a really extensive test suite before
general release.  Maybe release it to ppl who are desparate for the fix
though...

I'd like to see the bugfix file included in the upgrade, somehow, too.

MikeS
<RemoveMEmikesmith_ozKILLspamspamrelaymail.net>

1997\06\11@011130 by Mike Smith

flavicon
face
From: Lars Johansson 6018384 <LRSSTOPspamspamspam_OUTSTOA.MOBILE.TELIA.SE>
To: spamBeGonePICLISTSTOPspamspamEraseMEMITVMA.MIT.EDU
Subject: Re: C-compilers for PIC
Date: Monday, 9 June 1997 18:49

;Does anyone know if there exists any WORKING C-compilers for PIC
;microcontrollers.  I have been using MPLAB-C for a while, and it is simply
;the WORST C-compiler I have ever tried.  The compiler crashes if you do
not
;carefully insert spaces and comments at all critical places in your code.
;If you are lucky enough to be able to run the compilator on your code, you
;can be quite shure that the code it produces is wrong.
;
;So, is this the only option out there??
;
;Hevard

Hi Hevard!
I couldn't agree more...
I have written a C-program and in one
line am I doing this calculation:
.
char nr_overflow=0;
char timer_value=0;
unsigned long period=0;
char x =1;
.
.
period=(timer_value+nr_overflow*256)/x;
.
.
When I multiplie the variabel nr_overflow with 256 everything works fine.

BUT, if I do the same thing but multiplie nr_overflow with 255, nothing
works. The value that period get, is totally wrong!!!!

It's behaving like c should.  When you multiply by 255, then all of the
arithmetic inside those brackets happens as 8 bit - and quite obviously
overflows.  It doesn't get promoted to long until *after* the arithmetic.
When you multiply by 256 - this is a 16 bit number - all of the other
operands get promoted to 16 bit, and the arithmetic is done in 16 bit.
Compare the generated code.  I'm sure you'll find that this is what's
happening.  If you really want to multiply by 255, and have it work, try
this...

period=(timer_value+(long)nr_overflow*255)/x;

This cast will force the promotion of the first arithmetic operation to
occur as 16 bit.  All following will happen that way as well.

MikeS
<KILLspammikesmith_ozspamBeGonespamrelaymail.net>

1997\06\11@073258 by Andy Kunz

flavicon
face
At 06:22 PM 6/10/97 -0500, you wrote:
>> At 07:46 AM 6/9/97 -0500, you wrote:
>> >I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
>> >doesn't have all those nasty limitations.  Want multi-dimensional arrays?
>> >No problem!  Want more than two arguments for a function?  No problem!
>>
>> Want bugs?  Want a new release every day?  Want operation and definition of
>> "correct" changed apparently on a whim?  Don't want docs?
>>
>> And that's my short list.
>
>As a user of the CCS compiler, I will readily admit that the problems you
>describe are indeed annoying.  On the other hand, compared with my MPLABC
>experience I'd say CCS is pretty good (if you call tech support because
>the compiler mis-evaluates an expression, would you rather get a response
>of "Yeah, it has that problem.  We may fix that in a month or two," or
>"Oops, that doesn't seem to work right.  I'll try to get it fixed by
>tomorrow."

Judging from what comes out of this list (especially from one South
African) the MPLAB-C is a few light-years behind CCS.  I just wish it would
be tested better before "release" and that things which work (such as the
interrupt handler) wouldn't be broken on a whim.  Current docs would be
nice, too.

See attached humor.

Andy

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
            "The Sixth Sense - The Sense of Humor"
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

People for Ethical Treatment of Software (PETS) announced today that
more software companies have been added to the group's "watch list"
of companies that regularly practice software testing.  "There is no
need for software to be mistreated in this way so that companies like
these can market new products," said Ken Grandola, spokesperson for
PETS. "Alternative methods of testing these products are available."

According to PETS, these companies force software to undergo lenghty
and arduous tests, often without rest, for hours or days at a time.
Employees are assigned to "break" the software by any means
necessary, and inside sources report that they often joke about
"torturing" the software.

"It's no joke," said Grandola.  "Innocent programs, from the day
they are compiled, are cooped up in tiny rooms and "crashed" for
hours on end.  They spend their whole lives on dirty, ill-maintained
computers, and are unceremoniously deleted when they're not needed
any more." Grandola said the software is kept in unsanitary
conditions and is infested with bugs. "We know that alternatives to
this horror exist," he said, citing industry giant Microsoft
Corporation as a company that has become successful without resorting
to software testing.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"The Sixth Sense - The Sense of Humor" is an open & free conference
to share humor with over 900 members.  Forward this one to a friend.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

SEND comments to the 6th-Sense moderator:  EraseMEFremerspamEraseMExc.org

SUBMIT your conference messages     To: @spam@6th-Sense@spam@spamspam_OUTxc.org

SUBSCRIBE to this free conference by sending the message:
   Subscribe 6th-Sense             To: spamBeGoneHubspamKILLspamxc.org

UNSUBSCRIBE to this free conference by sending the message:
   Unsubscribe 6th-Sense           To: .....Hubspam_OUTspamxc.org

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
WARNING - The 6th-Sense might be considered funny.
Please read our disclaimer. Send this message to get the disclaimer:
   Get 6th-Sense disclaimer        To: TakeThisOuTHub.....spamTakeThisOuTxc.org
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\06\11@081323 by Stephen R. Synakowski

flavicon
face
>
> Exactly! I've been bitchin' & moanin' for 8 @#%$%(&*%^&*% months about
> the
> ^&(&%$*$$^ lack of %*&$&H:\pic\pic archive 2 working interupt service routine context
> saving
> code. I hacked some code from the Bytecraft compiler which worked
> perfectly.
>
> About two weeks ago a Mchip engineer noted that MPLAB-C now also
> features
> this code (at last).
>
> I tried Mchip's code yesterdDesign - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================
······················9EVLN(Saturn Can't Produce Enough Cars to Meet Demand,EV1)
·····Cx············è
·· ó··—·Saturday28 00:20:44 1996········® ¢ý··············ÿÿ············Bruce D. Parmenteriscussion List·······························5EVLN(Toyota to market electric recreati mitvma.mit.edu (IBM VM SMTP
         V2R3) with TCP; Wed, 11 Jun 97 07:30:57 EDT
Received: from montana.fast.net (ppp-abe-319.fast.net [205.147.223.19]) by
         post1.fast.net (8.8.5/8.8.5) with SMTP id HAA22848 for
         <TakeThisOuTPICLISTKILLspamspamspamMITVMA.MIT.EDU>; Wed, 11 Jun 1997 07:31:24 -0400 (EDT)
X-Sender: .....montanaspamRemoveMEpop.fast.net
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
References: <RemoveME3.0.1.32.19970610063243.006a7008spamspamBeGonepop.fast.net>> Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id:  <
spamBeGone3.0.1.32.19970611072529.006b6158@spam@spamspam_OUTpop.fast.net>> Date:         Wed, 11 Jun 1997 07:25:29 -0400
Reply-To: pic microcontroller discussion list <
TakeThisOuTPICLISTspamspammitvma.mit.edu>
Sender: pic microcontroller discussion list <PICLISTEraseMEspammitvma.mit.edu>
From: Andy Kunz <RemoveMEmontanaEraseMEspamspam_OUTFAST.NET>
Subjece software testing.  "There is no
ne
Received: from MIT.EDU (18.69.0.28) by org.org
with SMTP (Apple Internet Mail Server 1.1); Wed, 11 Jun 1997 06:07:11 -0700
Received: from MITVMA.MIT.EDU by MIT.EDU with SMTP
       id AA14110; Wed, 11 Jun 97 09:06:09 EDT
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R3)
  with BSMTP id 8555; Wed, 11 Jun 97 09:06:43 EDT
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU
(LMail V1.2b/1.8b) with BSMTP id 5156; Wed, 11 Jun 1997 09:06:40 -0400
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV release 1.8c) with
         NJE id 7765 for @spam@PICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU; Wed, 11 Jun 1997 09:06:33
         -0400
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2b/1.8b) with BSMTP id 5138; Wed, 11 Jun 1997 09:05:59 -0400
Received: from sally.renishaw.co.uk (194.200.145.10) by mitvma.mit.edu (IBM VM
         SMTP V2R3) with TCP; Wed, 11 Jun 97 09:05:55 EDT
Received: by sally.wotton.renishaw (1.39.111.2/16.2) id AA132984880; Wed, 11
         Jun 1997 14:14:40 +0100
Received: from schroder.wotton.renishaw(172.16.2.34) by sally.wotton.renishaw
         via smap (V1.3) id sma013293; Wed Jun 11 14:14:34 1997
Received: from  by schroder.wotton.renishaw with SMTP (1.39.111.2/16.2) id
         AA043114409; Wed, 11 Jun 1997 14:06:49 +0100
X-Openmail-Hops: 1
Priority: Urgent
Message-Id:  <d00JD7u000000000@MHS>
Date:         Wed, 11 Jun 1997 14:05:00 +0100
Reply-To: pic microcontroller discussion list <EraseMEPICLISTspam@spam@mitvma.mit.edu>
Sender: pic microcontroller discussion list <@spam@PICLISTspam_OUTspam.....mitvma.mit.edu>
From: Michael Warwick <WARWICK_MICHAEL/spamBeGoneGBEraseMEspamRENISHAW.CO.UK>
Subject:      Re: MPLAB not compliant to Windows NT 4.0
To: PICLISTspamBeGonespammitvma.mit.edu

Item Subject: cc:Mail Text
  > To make it work, they'll still have to write to the hardware, but it will
  > have to be done in a Vxd device driver.  Maybe MicroChip don't have any
  > programmers that can use the DDK...   Answer - vote with your dollars.
  > (Actually, I got mine free from one of their seminars - thanks MicroChip &
  > Zatek)
    Actually VxD's are only for Win 3.x and Win 95.  To write to hardware
    in NT you have to write a Kernel mode Physical Device Driver.
    A simple one of these is not very difficult, but when you work in
    "kernel world" it is REALLY easy to hose the entire OS.  (My favorite
    bug so far was a pointer bug that wrote into CMOS memory.)


    I have a simple driver for the hardware. I just don't have the source
    to write to the driver that writes to the port if anybody can change
    the source so that it talks to rint in stead of int then i might have
    a solution -it's worth a try.....

    Any body got the source code?

1997\06\11@083533 by Gene Norris

picon face
Which compiler do you suggest Andy?  I am in the process of evaluating one
for my use.  Cost is a consideration as well as function.

Thanks, Gene.

At 06:32 AM 6/10/97 -0400, you wrote:
{Quote hidden}

Gene Norris
RemoveMEGnorris@spam@spamspamBeGoneearthlink.net
E. Windsor, NJ USA

1997\06\11@101849 by John Payson

flavicon
face
> When I multiplie the variabel nr_overflow with 256 everything works fine.
>
> BUT, if I do the same thing but multiplie nr_overflow with 255, nothing
> works. The value that period get, is totally wrong!!!!
>
> It's behaving like c should.  When you multiply by 255, then all of the
> arithmetic inside those brackets happens as 8 bit - and quite obviously
> overflows.  It doesn't get promoted to long until *after* the arithmetic.
> When you multiply by 256 - this is a 16 bit number - all of the other
> operands get promoted to 16 bit, and the arithmetic is done in 16 bit.
> Compare the generated code.  I'm sure you'll find that this is what's
> happening.  If you really want to multiply by 255, and have it work, try
> this...

C is required to promote all operands to either "int" or "unsigned
int" before performing calculations if doing so will affect the result; C
(per both K&R and ANSI) mandates than "int" means a type whose range is at
least -32767 to 32767 and "unsigned int" is a type whose range is at least
0 to 65535.

Much as I like the CCS compiler, its handling of multiplies is IMHO quite
broken.  An 8x8->16 multiply is not significantly slower than 8x8->8, but
unless you write your on multiply (as I usually do) the only way to get a
16 bit result from the multiply is to do a 16x16 multiply (MUCH slower!)

> period=(timer_value+(long)nr_overflow*255)/x;
>
> This cast will force the promotion of the first arithmetic operation to
> occur as 16 bit.  All following will happen that way as well.

Faster would be this:

typedef struct TWOBYTES {char l, h;};
typedef union BYTEHL {long w; TWOBYTES b;};

long mult255(ub val)
{
 BYTEHL temp;

 temp.b.h=val; temp.b.l = 0;
 temp.w -= val;
 return temp.w;
}

1997\06\11@103706 by Gerhard Fiedler

picon face
At 06:32 10/06/97 -0400, Andy Kunz wrote:
>At 07:46 AM 6/9/97 -0500, you wrote:
>>I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
>>doesn't have all those nasty limitations.  Want multi-dimensional arrays?
>>No problem!  Want more than two arguments for a function?  No problem!
>
>Want bugs?  Want a new release every day?  Want operation and definition of
>"correct" changed apparently on a whim?  Don't want docs?

So what's your suggestion? I just started to use the CCS PCM compiler...


-------------------------------------
Gerhard Fiedler <.....gerhard@spam@spamEraseMEpobox.com>
S‹o Paulo - Brazil

1997\06\11@105411 by Mayes uk

flavicon
picon face
In message  <.....199706102322.SAA05879RemoveMEspamMars.mcs.net> .....PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU writes:
> > At 07:46 AM 6/9/97 -0500, you wrote:
> > >I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
> > >doesn't have all those nasty limitations.  Want multi-dimensional arrays?
> > >No problem!  Want more than two arguments for a function?  No problem!
> >
> > Want bugs?  Want a new release every day?  Want operation and definition of
> > "correct" changed apparently on a whim?  Don't want docs?
> >
> > And that's my short list.
>
> As a user of the CCS compiler, I will readily admit that the problems you
> describe are indeed annoying.  On the other hand, compared with my MPLABC
> experience I'd say CCS is pretty good (if you call tech support because
> the compiler mis-evaluates an expression, would you rather get a response
> of "Yeah, it has that problem.  We may fix that in a month or two," or
> "Oops, that doesn't seem to work right.  I'll try to get it fixed by
> tomorrow."
>

The tolerance you guys seem to have amazes me.

If one of these compilers mis-evaluates an expression, it can take
hours if not days to discover where the code is going wrong. To then
have someone on the phone say they'll *try* and fix it by tomorrow
doesn't seem to be enough in the way of compensation.

Remember, C is not new and these compilers are a few years old. There
really is no excuse.


Mike Watson

1997\06\11@111641 by trogers

flavicon
face
Andy Kunz wrote:

> Want bugs?  Want a new release every day?  Want operation and definition of
> "correct" changed apparently on a whim?  Don't want docs?
>
> And that's my short list.

In my experience the CCS stuff is worth the cost and the maintenence
fee. There
are plenty of details that could be different, but this is not a perfect
world.
The package doesn't have the 11 feet of docs that come with, say, VMS;
it doesn't
cost as much, either. The CCS stuff is about middle of the pack for
software
these days, and its not through dishonesty or lack of depth of
knowledge, as is
often the case. After a careful tryout I recommend it.

You will have to know what you are doing to get benefit from it, but
that's the
way life is.

Tom Rogers  VP-R&D  Time Tech Inc.

1997\06\11@113915 by John Payson

picon face
> > As a user of the CCS compiler, I will readily admit that the problems you
> > describe are indeed annoying.  On the other hand, compared with my MPLABC
> > experience I'd say CCS is pretty good (if you call tech support because
> > the compiler mis-evaluates an expression, would you rather get a response
> > of "Yeah, it has that problem.  We may fix that in a month or two," or
> > "Oops, that doesn't seem to work right.  I'll try to get it fixed by
> > tomorrow."
> >
>
> The tolerance you guys seem to have amazes me.
>
> If one of these compilers mis-evaluates an expression, it can take
> hours if not days to discover where the code is going wrong. To then
> have someone on the phone say they'll *try* and fix it by tomorrow
> doesn't seem to be enough in the way of compensation.
>
> Remember, C is not new and these compilers are a few years old. There
> really is no excuse.

I have found that, with the CCS compiler, I can usually get jobs done
faster than I'd be able to in assembly--despite the compiler's quirks.
Generally, any time I try something new with the compiler I take a
look at its generated code.  If the code looks good, then I can use that
technique with confidence; if not, I do a workaround.

I will admit that sometimes the compiler's bugs do bite me in the derriere
when I'm not expecting them.  For example, the following will fail in CCS:

 printf("%02u-%c%c%c-%02u", day, m1,m2,m3, year);

despite the fact that many more complicated expressions work fine (the
compiler will try to "compress" the three "%c"'s).  While compression is
fine and even laudible in an expression like

 printf("\n--------------------\n");

which CCS will code as "print a newline, print twenty dashes, and print
another newline", the compression of "%c%c%c" produces bogus code.

As for your comment about "tolerance" for bugs, such tolerance is a product
of the *lack* of *good* C compilers for the PIC (though I've been told that
Bytecraft is decent (but a bit pricey) and HiTech's looks promising).  I
wouldn't accept anything close to this level of problems on a PC compiler
or an 8x51 compiler because solid products are readily available.  Hopefully
the PIC will reach that point within a few years as well.

1997\06\11@135905 by mbonner

flavicon
face
> As for your comment about "tolerance" for bugs, such tolerance is a product
> of the *lack* of *good* C compilers for the PIC (though I've been told that
> Bytecraft is decent (but a bit pricey) and HiTech's looks promising).  I
> wouldn't accept anything close to this level of problems on a PC compiler
> or an 8x51 compiler because solid products are readily available.  Hopefully
> the PIC will reach that point within a few years as well.

I've been using Bytecraft for almost a year, and have found it good.  It
appears to generate excess code (especially to do with bank switching)
but I have yet to reach the program memory limit of my 16C74.  When (and
if) I do, I'll fix things in asm.

Re price: a buggy $99 compiler vs a (so far) fully functional $900
compiler would not please my boss if it delayed product development -
worth significantly more than the $800 difference in up-front costs.
That $800 "savings" would also be used up after 32 hours of debugging
flaky compiled code at the asm level and the time spent with product
support.  Bytecraft simply e-mails me upgrades.

More importantly - I have to support a fellow Canadian company ;-)

- Matt

1997\06\11@152218 by trogers

flavicon
face
Mayes uk wrote:

> The tolerance you guys seem to have amazes me.
>
> If one of these compilers mis-evaluates an expression, it can take
> hours if not days to discover where the code is going wrong. To then
> have someone on the phone say they'll *try* and fix it by tomorrow
> doesn't seem to be enough in the way of compensation.
>
> Remember, C is not new and these compilers are a few years old. There
> really is no excuse.
>
> Mike Watson

Politly, Mike, Nuts.

I've documented a lot of the behavior of the CCS stuff that I didn't
like
to the people at CCS. In every case I checked several sources, including
Plauger's book on the ANSI spec. I also ran examples on the 5 other C
compilers that I own, which come from big and little guys you probably
know. In many cases the other compilers also give different results. I
have yet to see a mis-evaluation; in every case that I haven't seen what
I expect, the compiler is operating as designed. Sometimes it follows
the
original K&R style, and sometimes the behavior is related to the
implementation.

But it has never taken hours to find.

Tom Rogers  VP-R&D  Time Tech Inc.

1997\06\11@155521 by Andrew Warren

face
flavicon
face
terogers <trogersEraseMEspam@spam@timetech.com> wrote:

> I've documented a lot of the behavior of the CCS stuff that I
> didn't like to the people at CCS. .... I have yet to see a
> mis-evaluation; in every case that I haven't seen what I expect,
> the compiler is operating as designed. Sometimes it follows the
> original K&R style, and sometimes the behavior is related to the
> implementation.

Tom:

Six months ago, I thought I'd give the CCS compilers a try... It
took about an hour to find a HUGE number of errors and problems,
including the following cases where the compiler (PCM version 2.204)
generated incorrect code:

       long v,w;   // v and w are 16-bit (unsigned) words.
       int x;      // x is an 8-bit (unsigned) word.

       w = 1 << x;
       x = 1 << w;
       w = x << 4;
       return (v & w) ? 1 : 0;
       if (++w) x = 1;
       if (--w) x = 1;
       if (w || x) x = 1;

After that experiment, of course, I gave up on the idea of using the
CCS compilers for anything serious and continued to use MPC.

-Andy

=== Andrew Warren - RemoveMEfastfwdspamspamBeGoneix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\06\11@180724 by Andy Kunz

flavicon
face
At 08:23 AM 6/11/97 -0400, you wrote:
>Which compiler do you suggest Andy?  I am in the process of evaluating one
>for my use.  Cost is a consideration as well as function.

If you don't mind bugs then the CCS because of cost of product.  I
wholeheartedly recommend their subscription program.

Jury is still out on Avocet, but if it's anywhere near as good as their
other products, I'll probably go that way.

There are nice things about CCS, such as the supplied libraries and it's
automatic removal of non-linked routines, also the "app builder" for
getting a project started ("PCW" product).  Their IDE isn't very standard,
and the editor sucks, IMHO.

I never tried ByteCraft.

In short, I don't recommend any of them 100%.  Take what you can get based
upon your own priorities.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\06\11@202218 by John Griessen

flavicon
face
>> I've documented a lot of the behavior of the CCS stuff that I
>> didn't like to the people at CCS. .... I have yet to see a
>> mis-evaluation; in every case that I haven't seen what I expect,
>> the compiler is operating as designed. Sometimes it follows the
>> original K&R style, and sometimes the behavior is related to the
>> implementation.
++++++++++++++++++++++++++++++
Is K&R style of such mythic quality that it deserves to be mixed with other
styles?  I think not.  Kernighan and Ritchie wrote such brainy,
intellectually motivated, nitpicky specifications that if you mix anything
else with their style, you're going to be gotten.  Be a purist, or find or
create everyman's yacc output that will satisfy like a Chesterfield.

And stop whining.

JG

1997\06\11@224440 by Mike Smith

flavicon
face
> From: John Payson <spamBeGonesupercatKILLspamspam@spam@MCS.COM>
> To: PICLISTspam_OUTspam@spam@MITVMA.MIT.EDU
> Subject: Re: C-compilers for PIC
> Date: Wednesday, 11 June 1997 18:41
>
> > When I multiplie the variabel nr_overflow with 256 everything works
fine.
> >
> > BUT, if I do the same thing but multiplie nr_overflow with 255, nothing
> > works. The value that period get, is totally wrong!!!!
> >
> > It's behaving like c should.  When you multiply by 255, then all of the
> > arithmetic inside those brackets happens as 8 bit - and quite obviously
> > overflows.  It doesn't get promoted to long until *after* the
arithmetic.
> > When you multiply by 256 - this is a 16 bit number - all of the other
> > operands get promoted to 16 bit, and the arithmetic is done in 16 bit.
> > Compare the generated code.  I'm sure you'll find that this is what's
> > happening.  If you really want to multiply by 255, and have it work,
try
> > this...
>
> C is required to promote all operands to either "int" or "unsigned
> int" before performing calculations if doing so will affect the result; C

^^^^^^^^^^^^^^^^^^^^^
Its in a variable - at compile - time it doesn't know if it will affect the
result.

> (per both K&R and ANSI) mandates than "int" means a type whose range is
at
> least -32767 to 32767 and "unsigned int" is a type whose range is at
least
{Quote hidden}

Much faster!  I use that TWOBYTES trick to split WORDS (long) into BYTES,
without the need to do two divides (well, one is a modulus op, but it calls
the same 16bit divide routine.)  I haven't actually looked at CCS's mult
/divide routines carefully, you really think they're bad? (as in slow, not
necessarily inaccurate)

MikeS
<spamBeGonemikesmith_oz@spam@spamrelaymail.net>

1997\06\11@224449 by Mike Smith

flavicon
face
----------
> From: Mayes uk <RemoveMEmikeEraseMEspamKILLspamD-M-G.DEMON.CO.UK>
> To: spamBeGonePICLISTspam_OUTspamRemoveMEMITVMA.MIT.EDU
> Subject: Re: C-compilers for PIC
> Date: Wednesday, 11 June 1997 18:30
>
> In message  <.....199706102322.SAA05879spamRemoveMEMars.mcs.net> PICLISTspam@spam@MITVMA.MIT.EDU
writes:
> > > At 07:46 AM 6/9/97 -0500, you wrote:
> > > >I really like CCS's "PCM" compiler for 16Cxx pics.  Works great, and
> > > >doesn't have all those nasty limitations.  Want multi-dimensional
arrays?
> > > >No problem!  Want more than two arguments for a function?  No
problem!
> > >
> > > Want bugs?  Want a new release every day?  Want operation and
definition of
> > > "correct" changed apparently on a whim?  Don't want docs?
> > >
> > > And that's my short list.
> >
> > As a user of the CCS compiler, I will readily admit that the problems
you
> > describe are indeed annoying.  On the other hand, compared with my
MPLABC
> > experience I'd say CCS is pretty good (if you call tech support because
> > the compiler mis-evaluates an expression, would you rather get a
response
{Quote hidden}

But - the sentence - 'fix it by tomorrow' - is what worries me!  Haven't
you ever fixed one bug in your s/w - only to find it causes another?  Take
another day and test it for interactions guys.

> Remember, C is not new and these compilers are a few years old. There
> really is no excuse.
>

Windows is a few years old, and is, of course, bug free.  Windows is
written by an organisation with programmers numbered in  the 1000's  CCS
has 1, so the codebase size comparison is reasonable.

MikeS
<EraseMEmikesmith_ozRemoveMEspamSTOPspamrelaymail.net>

1997\06\11@224457 by Mike Smith

flavicon
face
{Quote hidden}

I'll assume that you did initialise x to a reasonable shift value here...
>
>         w = 1 << x;

This one's bitten me too - Mark at CCS insists its legit K&R, so I do this
-

w = 1L << x;
or, if it wasnt a const
w = (long)x << 10;

Don't know about the rest - I'll give it a bash on the latest version and
tell you what it does now...

>         x = 1 << w;
>         w = x << 4;
>         return (v & w) ? 1 : 0;
>         if (++w) x = 1;
>         if (--w) x = 1;
>         if (w || x) x = 1;
>
> After that experiment, of course, I gave up on the idea of using the
> CCS compilers for anything serious and continued to use MPC.

MPC seems to have its share of detractors, too.

MikeS
<mikesmith_ozspamspamrelaymail.net>

1997\06\12@002703 by John Payson

flavicon
face
> > C is required to promote all operands to either "int" or "unsigned
> > int" before performing calculations if doing so will affect the result; C
> ^^^^^^^^^^^^^^^^^^^^^
> > (per both K&R and ANSI) mandates than "int" means a type whose range is
> at
> > least -32767 to 32767 and "unsigned int" is a type whose range is at
> least
> > 0 to 65535.

> Its in a variable - at compile - time it doesn't know if it will affect
> the result.

If the compiler can't determine whether the promition is necessary, the
promotion is required.  On the other hand, it's often fairly easy to
determine most of the cases where promotions can be eliminated.  I have
the beginnings of a PIC compiler I was working on which in fact does just
that.  The algorithm I used (not necessarily the best, but it works quite
adequately) is to build each expression into a tree with each node labeled
according to its maximum possible integer size (for example, a multiply
node's maximum size is the sum of its two decentants' sizes, up to a
maximum of 4).  Then it goes through on a second pass and evaluates each
node's size and that of its children; if a child node's integer size is
excessive given its parent's size, it will be downsized (for example, if
the result of a multiply will be placed in a two-byte integer, the
operands will be shrunk if they were larger than two bytes).

There are a couple of tricky cases: most notably addition and subtraction.
The result of an add or subtract will be the size of the larger operand,
plus 1, EXCEPT that this "plus one" side won't propagate through
additional additions [e.g. in

{
 uint16 x,y,z;
 uint32 l;

 l=x+y+z;
}

the addition of x+y will be extended to 3 bytes.  The addition of that
3-byte quantity to the two-byte "z", however, will still be three bytes.]
Signed math also poses its own problems, and the code has no way of
knowing how big numbers will really get.  For example, in the code:

{
 uint8 x,y,z;
 uint32 l;

 l=(x+y)*z;
}

the compiler has no way of knowing whether it's actually necessary to
calculate the multiplication as 16x8->24, 16x8->16, or 8x8->16;
consequently, it will calculate it as the latter.  This is especially
problematical in cases such as:

{
 uint8 t,u,v,w, y,z;

 z=(t+u)*(v+w) >> y;
}

In this case, the compiler has no choice but to process the multiplication
as 16x16->32 even though it's unlikely that the full 32 bits will be
needed.  On the other hand, such cases aren't terribly common and it's
probably better for the compiler to ensure that all results that fit
within the -2147483648..2147483647 range will be handled correctly [even
if slowly] than to produce code which will be faster but may produce
incorrect results.

BTW, there is no support for unsigned 32 bit integers (though signed 32
and unsigned 24 are supported).  This restriction was necessary to ensure
that the type promotion rules behave reasonably; otherwise, it's unclear
what should happen to an expression such as

{
 uint16 x,y,z;
 int24 w;  /* signed */

 w = (x*y-z) / 512;
}

The (x*y-z) expression result may be anything from 4294836225 to -65535.
Any of those results would fit within "w" after the division, but the
compiler has no way of knowing whether the inner expression should be
promoted to an unsigned int32 (in which case results less than zero would
be miscomputed) or a signed int32 (in which case results over 2147483647
would be miscomputed).  Mandating that it will be a signed int32 replaces
this ambiguity with a simple rule: if all intermediate results are within
the proper range, the calculations will be done correctly.

{Quote hidden}

I don't think the CCS's routines are terrible or anything (they're decent,
but not exceptional).  On the other hand, a 16x16->16 multiply has to do
about 3-4 times as much work as an 8x8->16 multiply.  It's therefore
unavoidable that it will be slower than an 8x8->16.

1997\06\12@025959 by Andrew Warren

face
flavicon
face
I wrote:

> > I gave up on the idea of using the CCS compilers for anything
> > serious and [have] continued to use MPC.

and Mike Smith <spam_OUTPICLISTspam_OUTspamspam_OUTMITVMA.MIT.EDU> replied:

> MPC seems to have its share of detractors, too.

   Name one, Mike... Seriously.

   I'm not implying that MPC has no detractors, of course; I'm only
   suggesting that a discussion like this should include comments
   from people who've actually used the compilers in question and
   who can point out SPECIFIC shortcomings.

   By the way, Mike, please don't take this as a personal
   criticism... I know you just meant that as an offhand comment,
   but I'd hate to see this discussion degenerate into a thread
   full of vague, second-hand innuendo.

   Anyway...

   It'd be best if any discussion of compiler bugs included some
   mention of the compiler version... ALL the compilers have had
   problems, but most are updated pretty regularly and the newer
   versions are usually much better than the old ones.  Here's my
   contribution:

   In its most-current incarnation (version 1.30d), MPC has very few
   problems... The only code-generation bug that I've seen involves
   "long far pointer" math on the 17Cxx parts:

       Unlike all other PICs, the 17Cxx parts allow reads and
       writes to the PROGRAM memory; in MPC, those program-space
       accesses are accomplished through the use of "far pointers".

       If you want to read or write the entire 16-bit word at a
       program-space address, you need to use "long" far
       pointers... To write 0x1234 to address 0x1000, for example,
       you'd do something like this:

           long far *p;    // In MPC, "long" is a 16-bit word.

           p = 0x1000;
           *p = 0x1234;

       So far, so good.

       The problem occurs when you try to perform any MATH on the
       pointer.  Let's say, for instance, that you want to fill 10
       contiguous locations with 0x1234... You'd probably do
       something like this:

           long far *p;    // In MPC, "long" is a 16-bit word.

           p = 0x1000;

           for (x = 10; x != 0; --x)
           {
               *p = 0x1234;
               ++p;
           }

       In C, "incrementing" a pointer doesn't necessarily add 1 to
       it; rather, it adds the SIZE of the object to which the
       pointer points.  That is, if you have a pointer to a 10-byte
       structure at address 0, "incrementing" that pointer will make
       it point to address 10.

       For "near" pointers (which MPC uses to point to addresses in
       the register space), pointer math works fine.

       When math is performed on "far" pointers, however, MPC
       fails: In the "for" loop above, p is erroneously incremented
       by TWO at each iteration, since it's a pointer to a "long"
       and MPC doesn't realize that each location in the program
       space is SIXTEEN bits wide, not eight.

   It'd be foolish to assume that this is the ONLY bug in MPC, of
   course, but I have a feeling that any others are likely to be
   just as obscure... Simple expression-evaluation bugs (like the
   ones I found in PCM six months ago) just don't seem to exist in
   the latest versions of MPC.

   -Andy

=== Andrew Warren - fastfwdspam_OUTspamix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\06\12@110213 by myke predko

flavicon
face
Just a couple of comments and a question regarding the current "C-Compiler"
debate.

>But - the sentence - 'fix it by tomorrow' - is what worries me!  Haven't
>you ever fixed one bug in your s/w - only to find it causes another?  Take
>another day and test it for interactions guys.
>
>> Remember, C is not new and these compilers are a few years old. There
>> really is no excuse.
>>
>
>Windows is a few years old, and is, of course, bug free.  Windows is
>written by an organisation with programmers numbered in  the 1000's  CCS
>has 1, so the codebase size comparison is reasonable.

Mike, I'm not sure if you're being facetious by this comment.

I've always thought that the best code was written by one or two people and
not the thousands (what does that say about Windows...).  A small team is
more aware of interactions (and is therefore able to avoid them).

Such things as UNIX, Motif, and VisiCalc are examples of ground breaking
software that was written by a small team or one person.

This, of course, is no excuse for not thoroughly testing software in a
logical/structured manner.  It also means that if there are few authors
involved in the development of a piece of software are locked into what I
call "the life and death relationship of software support" (ie you're
supporting it until you die).


Is anybody looking at Java for the PIC (or other microcontrollers)?  The
more I look at compilers for (embedded) microcontrollers, the more it seems
like the "C" way of handling data is not that appropriate (ie pointers are
not that valuable/appropriate, take up too much space, and don't really have
built-in processor hardware that would make them more efficient).  Java's
methods of handling data seem to be more appropriate and will result in more
efficient assembly/object code.


Lastly, how do the various compilers handle negative numbers?  This question
originally comes from a comment Andy Warren made a number of months ago
regarding how the PIC doesn't really handle negative numbers.

Well, I spent a few hours a couple of nights ago playing with the Basic
Stamp 1 and I see what he means.  A two's complement "negative" number isn't
necessarily a negative number (especially in the Stamp).

For example, say you were going to add -5 (which is defined as an 8 bit
byte) by 7 (which is defined as a 16 bit word) and put the result in a 16
bit word; what would your answer be?

The Stamp converts all parameters to sixteen bit values before executing an
arithmetic opertor.

So, -5 is actually 0x0FB (or $FB in PBASIC Speak), which is treated as
0x000FB when the add operator code is called.

The result is 0x0102 ($102) and not 2 as logic would dictate.

Now, in my trusty Microsoft "C" Compiler on my PC, this can be done
(defining the variables as "char" and "int) and the answer "2" will be
produced.  But as I look at the code, a "CBW" (Convert Byte Word)
instruction, which converts a byte (half register) into a signed word
(sixteen bits or full register), is executed before the addition takes place.

What do the PIC C Compilers do and is this where people have been saying you
have to look at the actual output code to make sure issues like this are
avoided?

myke

"Aliens are really just the same as us, only their molecules are different"
- Will Robinson

1997\06\12@113208 by tjaart

flavicon
face
Mike Smith wrote:
{Quote hidden}

No Problem ;)

{Quote hidden}

Just note that the newer version of MPC is *NOT* anything like MPLAB-C.
MPC is a much better product.

--
Friendly Regards

Tjaart van der Walt
spam_OUTtjaartspamKILLspamwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             WASP International  http://wasp.co.za           |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8973  |
|_____________________________________________________________|

1997\06\12@140131 by mike

flavicon
picon face
In message  <RemoveME339EF7F0.53EFRemoveMEspamEraseMEtimetech.com> KILLspamtrogersspamspamBeGonetimetech.com writes:
>
> > The tolerance you guys seem to have amazes me.
> >
> > If one of these compilers mis-evaluates an expression, it can take
> > hours if not days to discover where the code is going wrong. To then
> > have someone on the phone say they'll *try* and fix it by tomorrow
> > doesn't seem to be enough in the way of compensation.
> >
> > Remember, C is not new and these compilers are a few years old. There
> > really is no excuse.
> >
> > Mike Watson
>
> Politly, Mike, Nuts.
>
> I've documented a lot of the behavior of the CCS stuff that I didn't
> like
> to the people at CCS. In every case I checked several sources, including
> Plauger's book on the ANSI spec. I also ran examples on the 5 other C
> cjÝk¤ˆ5—nþo¯lqbÐßÎÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿðÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ·······························································································································································································································································ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿðÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ·······························································································································································································································································I-/C–H-/C–G-3C–
F.3D–D/1D–        C63D–C</E–?=3E–

1997\06\12@141632 by Mayes uk

flavicon
picon face
In message  <m0wcBLR-001BnkCspamspamdiplomatic.passport.ca> RemoveMEPICLISTspamBeGonespamRemoveMEMITVMA.MIT.EDU
writes:
> Just a couple of comments and a question regarding the current "C-Compiler"
> debate.
>
> >But - the sentence - 'fix it by tomorrow' - is what worries me!  Haven't
> >you ever fixed one bug in your s/w - only to find it causes another?  Take
> >another day and test it for interactions guys.
> >
> >> Remember, C is not new and these compilers are a few years old. There
> >> really is no excuse.
> >>
> >
> >Windows is a few years old, and is, of course, bug free.  Windows is
> >written by an organisation with programmers numbered in  the 1000's  CCS
> >has 1, so the codebase size comparison is reasonable.
>
> Mike, I'm not sure if you're being facetious by this comment.
>

I do hope the Windows paragraph is not being attributed to me.

Regards,


Mike Watson

1997\06\12@143102 by .EDU>

flavicon
face
{Quote hidden}

Yes, you can!  (Of course, you have to have Vpp present to do so...)

> 0x1000 12 <- pointer starts here
> 0x1001 34
> 0x1002 12 <- pointer after one iteration
> 0x1003 34
> (I don't know whether MPC is big or little endian)

The 17Cxx parts have 16-bit words on the code-space (EPROM) side, so:
0x1000 1234 <- pointer starts here
0x1001 FFFF
0x1002 1234 <- pointer after one iteration
0x1003 FFFF
0X1004 FFFF <- pointer after second iteration
Even though the TABLRD and TABLWT instruction pass one byte at a time, the
program memory must be given a 16-bit visit on every other byte, and TBLPTR
is a (16-bit) pointer to 16-bit words, not to bytes.

I'm not sure whether you can call the 17Cxx either little-endian OR
big-endian, except that low/high byte pairs are allocated low address for
the low-order byte (e.g., PRODL/PRODH are 18h/19h) that makes it
little-endian, eh?

Peter F. Klammer, Racom Systems Inc.                   KILLspamPKlammerspamBeGonespamACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1997\06\12@161143 by trogers

flavicon
face
I've documented a lot of the behavior of the CCS stuff that I
didn't like to the people at CCS. .... I have yet to see a
mis-evaluation; in every case that I haven't seen what I expect,
the compiler is operating as designed. Sometimes it follows the
original K&R style, and sometimes the behavior is related to the
implementation.
-------------
Is K&R style of such mythic quality that it deserves to be mixed with
other
styles?  I think not.  Kernighan and Ritchie wrote such brainy,
intellectually motivated, nitpicky specifications that if you mix
anything
else with their style, you're going to be gotten.  Be a purist, or find
or
create everyman's yacc output that will satisfy like a Chesterfield.

And stop whining.
-------------

Hmmm..  Which of these sounds like whining?

1997\06\12@171207 by Andrew Warren

face
flavicon
face
Reply-To: @spam@pklammerSTOPspamspam@spam@acm.org Peter F. Klammer
<PKLAMMERspamBeGonespamspamBeGoneCASTLE.CUDENVER.EDU> wrote:

> > Can you do accesses to program space in [the 17Cxx parts],
> > unlike the 16cxx's?
>
> Yes, you can!  (Of course, you have to have Vpp present to do so...)

   Pete:

   Vpp is only required if your program space is EPROM; if it's
   flash, EEPROM, RAM, or memory-mapped I/O, you don't need Vpp.

   -Andy

=== Andrew Warren - spamBeGonefastfwdspamix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\06\12@172806 by Andrew Warren

face
flavicon
face
myke predko <spam_OUTPICLISTSTOPspamspamMITVMA.MIT.EDU> wrote:

{Quote hidden}

Myke:

Yeah, this is precisely the sort of thing that I was demonstrating
with the half-dozen examples of PCM v2.204 failures I posted a couple
of days ago.

In your example, the bug is very obvious:  When -5 is converted to a
16-bit number (C programmers would say "cast to a 16-bit number"),
the Stamp fails to correctly propogate the sign bit leftward... The
number SHOULD have been changed to 0xFFFB, not 0x00FB.

-Andy

=== Andrew Warren - RemoveMEfastfwdspamspamix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\06\12@180005 by Andrew Warren

face
flavicon
face
Mike Smith <TakeThisOuTPICLISTspamspamRemoveMEMITVMA.MIT.EDU> wrote:

> > MPC seems to have its share of detractors, too.

I replied:

> Name one, Mike.

and Mike replied:

> Just have a look at the number of happy, satisfied customers for
> MPLAB-C

   Mike:

   MPLAB-C is NOT the same as MPC.

   MPC is Bytecraft Limited's compiler; MPLAB-C, Microchip's
   compiler, is based on (and still almost identical to) a VERY old
   version of MPC.

{Quote hidden}

   Um, yeah.  Re-read the first paragraph of my description of the
   problem.

> 0x1000 12 <- pointer starts here
> 0x1001 34
> 0x1002 12 <- pointer after one iteration
> 0x1003 34

   No... Since the 17Cxx program-memory is 16 bits wide, THIS is
   what actually happens when the pointer's erroneously incremented
   by two:

       0x1000 1234 <-- pointer starts here
       0x1001 0000
       0x1002 1234 <-- pointer after one iteration
       0x1003 0000

> A similar thing is likely to happen with the 16c77, given that some
> of its RAM is out of reach of the FSR.

   I don't think so.

   -Andy

=== Andrew Warren - KILLspamfastfwdspamspamspam_OUTix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\06\12@190952 by Lee Jones

flavicon
face
{Quote hidden}

Incorrect.  Not all memory architechtures are octet-address oriented.

Lots of commonly known CPUs ARE octet-address oriented.  Examples
include the Intel X86 series, Motorola 68000, IBM 360/370, and the
DEC PDP-11.  Since the PDP-11 is built that way and the original
designers of UNIX & C developed on it, most C compilers (and C
programmers) assumes it's always true.  It isn't.

Some memory architechtures have a word size other than 8-bits.
For example, each memory location/address in a DEC PDP-8 is 12
bits, in a DEC PDP-10 is 36 bits, in a DEC PDP-15 is 18 bits,
and in a CDC 6000 series is 60 bits.  In each of these machines,
incrementing a memory address pointer aims at the next location
of XX bits, where XX is _not_ equal to 8.

In the PIC 17C4X's program memory, the word size is 16 bits.

In all PICs, the data memory does use octet-oriented addresses.
Each address represents a location holding 8 bits (word size = 8).


> Maybe its a mis-understanding on my part of MPC, and its use of the far
> modifier, or ignorance of the 17xxx parts.  Can you do accesses to
> program space in them, unlike the 16cxx's?

Yes.  See the "Table reads and table writes" section in the 17C4X
documentation and the TLWT, TABLWT, TLRD, and TABLRD instructions.


> 0x1000 12 <- pointer starts here
> 0x1001 34
> 0x1002 12 <- pointer after one iteration
> 0x1003 34

In PIC 17C4X program memory, this is incorrect.  Your drawing
should be:

   0x1000  1234  <- pointer starts here
   0x1001  ????  <- location missed due to bug
   0x1002  1234  <- pointer after one interation


> (I don't know whether MPC is big or little endian)

Little or big endian is dependant on the CPU/memory architechture,
not the compiler.  It implies that objects larger than 8 bits are
written 8 bits at a time.  In the PIC 17C4X's program space, it's
a non-issue as 16-bit words are written as whole quantities.

                                               Lee Jones

-------------------------------------------------------------------
Jones Computer Communications             leeRemoveMEspamfrumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------

1997\06\12@193023 by Clyde Smith-Stubbs

flavicon
face
On Thu, Jun 12, 1997 at 03:45:17PM -0700, Lee Jones wrote:

> Little or big endian is dependant on the CPU/memory architechture,
> not the compiler.  It implies that objects larger than 8 bits are
> written 8 bits at a time.

Neither of these statements is correct. The first one is true only if
the architecture actually supports accessing data as either single
bytes or as larger objects. On the PIC 16Cxx chips the program memory
can only be accessed as words, so whether the high byte comes first or
not is neither determinable nor relevant, and the data memory can
only be accessed as single bytes, so the order in which bytes of a 16
bit integer or larger are stored is entirely up to the programmer (or
compiler writer).

As it happens, we have chosen to implement C on the PIC as little-endian,
partly because little-endian is inherently Better (others disagree
with this, of course) but also because the popular INHX8M format
used for representing PIC code words as bytes does so in a little-endian
format.

Other compilers use big-endian on the same hardware. On a 68000 though,
you must use big-endian because the hardware is big-endian - this is a
result of its bus structure.

I actually got caught out when designing an H8/300H board, which is a
big-endian processor with an external bus that can be used in either
16 or 8 bit mode. I assumed that in 8 bit mode it read and wrote data
on lines D0-D7 - in fact because it is big-endian, the low order data
is read and written on D8-D15, and this is what is used for the 8 bit
bus. That required a lot of cutting and jumpering!

--
Clyde Smith-Stubbs   |HI-TECH Software,      |Voice: +61 7 3354 2411
EraseMEclydeSTOPspamspamRemoveMEhtsoft.com     |P.O. Box 103, Alderley,|Fax:   +61 7 3354 2422
http://www.htsoft.com|QLD, 4051, AUSTRALIA.  |PGP: finger spam_OUTclydeRemoveMEspamEraseMEhtsoft.com
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\06\12@202835 by John Payson

flavicon
face
> > I don't get it.  You are storing a 2 byte value at a pointer location, then
> > incrementing the pointer.  If it only increments the pointer by one, or
> > indeed any other number but two, the pointer will be pointing at the wrong
> > location.
>
>
> Incorrect.  Not all memory architechtures are octet-address oriented.
[snip]
> Some memory architechtures have a word size other than 8-bits.
> For example, each memory location/address in a DEC PDP-8 is 12
> bits, in a DEC PDP-10 is 36 bits, in a DEC PDP-15 is 18 bits,
> and in a CDC 6000 series is 60 bits.  In each of these machines,
> incrementing a memory address pointer aims at the next location
> of XX bits, where XX is _not_ equal to 8.

In standard C, the following are the requirments for pointers and types:

[1] sizeof(char)==1.  Even if the architecture requires multiple addresses
to actually store a character, that should be transparent to the user.

[2] sizeof(long) >= sizeof(int) >= sizeof(short)

[3] sizeof(double) >= sizeof(float)

[4] The types 'unsigned char, unsigned int, and unsigned long' must be
able to support--at minimum--the ranges 0..255, 0..65535, and
0..4294967295.

[5] The types 'signed char, signed int, and signed long' must be able to
support--at minimum--the ranges -127..127, -32767..32767, and
-2147483647..2147483647.

[6] The 'char' type may be signed or unsigned, provided it is capable of
expressing the entire C character set [i.e. all the characters that may
appear outside of string literals or comments in a valid C program] as
positive numbers.  For ASCII-based machines, the entire C character set
fits below 127, so this poses no restriction.  On an EBCDIC machine,
however, the 'char' type must be capable of expressing the numbers 0..249
[if memory serves] and would thus either have to be larger than 8 bits or
else 8-bit unsigned.

[7] All standard C types, including structures, pointers, and arrays have
integer sizes (expressed in units of type char).  [Implentation-specific
extensions are not covered by this criterion, so types such as 'bit' do
not pose a problem].

[8] For any type of pointer 'foo', {foo++;} will increment foo by the size
of a (*foo).

Note that ANYTHING claiming to be a C compiler should meet all of these
rules (it's distressing how many don't--even the CCS compiler which I
generally like).  While it's common that type 'char' is 8 bits, it's not
required (from what I've read, on the C compiler for the Cray super-
computer, sizeof(char)==sizeof(short)==sizeof(int)==sizeof(long)==1 [64
bits].  On the TI 3205x C compiler [a $20 DSP chip] char's and int's are
both 16 bits.  While it would be more space-efficient for the compiler to
pack two bytes per word, doing so would require enlarging the size of a
(char*) since the address space is 65536 16-bit words; it was easier to
simply ignore the unused half of each word.

If this is what the MPC compiler is doing, it's well within standard
behavior.  If it's packing the bytes two per word and incrementing the
pointer by two bytes worth, then it's acting in error.  If you're packing
the bytes two per word (e.g. you created an array of constant integers)
then you're making a non-portable assumption (that sizeof(int)==2).

1997\06\12@225812 by Mike Smith

flavicon
face
{Quote hidden}

Versionitus strikes again.  MPC *looks* more like a contraction of MPLAB-C
than a contraction of ByteCraft compiler.  I'll try to be more careful in
future...

{Quote hidden}

As pointed out in a previous mail - I was thinking PC - where you can
access on byte boundaries this way.

MikeS
<mikesmith_ozspam_OUTspam@spam@relaymail.net>

1997\06\12@225820 by Mike Smith

flavicon
face
> From: myke predko <.....mykespamspam.....PASSPORT.CA>
> To: PICLISTKILLspamspamEraseMEMITVMA.MIT.EDU
> Subject: Re: C-compilers for PIC
> Date: Friday, 13 June 1997 00:29
>
> Just a couple of comments and a question regarding the current
"C-Compiler"
> debate.
>
> >But - the sentence - 'fix it by tomorrow' - is what worries me!  Haven't
> >you ever fixed one bug in your s/w - only to find it causes another?
Take
{Quote hidden}

I am!  Compleatly! <g> I should have put a :) there I guess...
>
> I've always thought that the best code was written by one or two people
and
{Quote hidden}

True - I've got custom software like that out there.

> Is anybody looking at Java for the PIC (or other microcontrollers)?  The
> more I look at compilers for (embedded) microcontrollers, the more it
seems
> like the "C" way of handling data is not that appropriate (ie pointers
are
> not that valuable/appropriate, take up too much space, and don't really
have
> built-in processor hardware that would make them more efficient).  Java's
> methods of handling data seem to be more appropriate and will result in
more
> efficient assembly/object code.
>

I'd alway looked at Java as being further away from the metal, as it were.
It certainly seems to be touted as an advantage when running on PC's - but
would be disadvantage for PIC's.  If you could make a Java VM - read;
interpreter - I suppose it would be no worse than the various Basics that
proliferate for the PIC, and could well be better.

> Lastly, how do the various compilers handle negative numbers?  This
question
> originally comes from a comment Andy Warren made a number of months ago
> regarding how the PIC doesn't really handle negative numbers.

CCS says it does signed now - I haven't tested that claim.

>
> Well, I spent a few hours a couple of nights ago playing with the Basic
> Stamp 1 and I see what he means.  A two's complement "negative" number
isn't
> necessarily a negative number (especially in the Stamp).
>
> For example, say you were going to add -5 (which is defined as an 8 bit
> byte) by 7 (which is defined as a 16 bit word) and put the result in a 16
> bit word; what would your answer be?
>
> The Stamp converts all parameters to sixteen bit values before executing
an
{Quote hidden}

place.
>
> What do the PIC C Compilers do and is this where people have been saying
you
> have to look at the actual output code to make sure issues like this are
> avoided?
>
Not how I do it.  I write the code function by function - compile and check
how it works - I check output initially to ensure it isn''t too bulky - and
perhaps do some tweaking to fix that - then check for correct operation.
If something doesn't work I go looking thru the code - C and LST files - to
find out why.  I'm using an ICE to do the debugging as well, BTW.  I'd hate
to trace some of the bugs without that.

MikeS
<EraseMEmikesmith_oz@spam@spam@spam@relaymail.net>

1997\06\13@021240 by Andrew Warren

face
flavicon
face
John Payson <@spam@PICLISTspamspamKILLspamMITVMA.MIT.EDU> wrote:

> In standard C, the following are the requirments for pointers and
> types:
>
>     [Rules 1 through 7 deleted....]
>
> [8] For any type of pointer 'foo', {foo++;} will increment foo by
> the size of a (*foo).
> ....
> If [MPC is] packing the bytes two per word and incrementing the
> pointer by two bytes worth, then it's acting in error.

   John:

   I suspect that you understand the symptoms of the problem
   perfectly, but that you mis-spoke and said "incrementing the
   pointer by two BYTES worth" when you meant "by two WORDS worth".

   Just to make sure, though, let me clarify a little:

   The pointer is pointing to 16-bit objects; the size of a (*p) is
   16 bits, and each one of these *p's fits in a single 16-bit
   memory location in the program space.

   However... MPC performs no special-case handling of the "long
   far" pointers that it uses to access program-space memory; it
   erroneously performs math on those pointers EXACTLY the same way
   that it (correctly) performs math on the "near" pointers that are
   used to access the register space.  That is, it increments
   pointers to "longs" (16-bit objects) by TWO, not one, whether
   they point to the 8-bit register space OR the 16-bit program
   space.

   By the way... "char far" pointers (pointers to 8-bit objects in
   the program space) work fine; MPC stores chars one per address,
   leaving 8 bits of each program-space memory location unused.

> If you're packing the bytes two per word (e.g. you created an array
> of constant integers) then you're making a non-portable assumption
> (that sizeof(int)==2).

   My array is of constant longs [in current versions of MPC,
   sizeof(long) is 16 bits].  If it HAD been an array of constant
   integers, it would've worked fine, but only because sizeof(int)
   is 8 bits in MPC.

   In any case, though, portability is the least of my concerns.

   -Andy

=== Andrew Warren - spamBeGonefastfwdRemoveMEspamEraseMEix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\06\13@022733 by Steve Hardy

flavicon
face
> From: Andrew Warren <RemoveMEfastfwdKILLspamspamRemoveMEIX.NETCOM.COM>
> [cut]
>     However... MPC performs no special-case handling of the "long
>     far" pointers that it uses to access program-space memory; it
>     erroneously performs math on those pointers EXACTLY the same way
>     that it (correctly) performs math on the "near" pointers that are
>     used to access the register space.  That is, it increments
>     pointers to "longs" (16-bit objects) by TWO, not one, whether
>     they point to the 8-bit register space OR the 16-bit program
>     space.

Perhaps the compiler should allow

long far * p;

*p = value1;
p += 0.5;       /* ?Que? */
*p = value2;


Rather non-ANSI don't you think?

Regards,
SJH
Canberra, Australia

1997\06\13@024900 by John Payson

flavicon
face
> > In standard C, the following are the requirments for pointers and
> > types:
> >
> >     [Rules 1 through 7 deleted....]
> >
> > [8] For any type of pointer 'foo', {foo++;} will increment foo by
> > the size of a (*foo).
> > ....
> > If [MPC is] packing the bytes two per word and incrementing the
> > pointer by two bytes worth, then it's acting in error.
>
>     I suspect that you understand the symptoms of the problem
>     perfectly, but that you mis-spoke and said "incrementing the
>     pointer by two BYTES worth" when you meant "by two WORDS worth".

Is the compiler storing consecutive items in your data structure in
consecutive words?  If so, incrementing a pointer should advance it to
the next address.  If not, it should increment the pointer in such a way
as to move from one item to the next.

>     Just to make sure, though, let me clarify a little:
>
>     The pointer is pointing to 16-bit objects; the size of a (*p) is
>     16 bits, and each one of these *p's fits in a single 16-bit
>     memory location in the program space.

Certainly each one CAN fit in a single word.  Are you also implying that
the compiler does, in fact, allocate them that way (while it would be
silly of the compiler to store values using only the low byte of each
word, it would not violate the C standard by so doing).

{Quote hidden}

Fair enough.  And you're saying the handling of int (16-bit) quantities
doesn't just store half of the number in each of two addresses?

> > If you're packing the bytes two per word (e.g. you created an array
> > of constant integers) then you're making a non-portable assumption
> > (that sizeof(int)==2).
>
>     My array is of constant longs [in current versions of MPC,
>     sizeof(long) is 16 bits].  If it HAD been an array of constant
>     integers, it would've worked fine, but only because sizeof(int)
>     is 8 bits in MPC.

The data type MPC calls an "int" is a "char".  The data type MPC calls a
"long" is an "int".  MPC does not, as far as I know, support "long"'s (the
only compiler I know that does is HiTech's beta).  Personally, I *NEVER*
use the defined type "int" to refer to an 8-bit number in CCS.  Instead I
*ALWAYS* do:

 typedef long ui; /* Unsigned int */
 typedef char ub; /* Unsigned byte */
 typedef short bit;

and occasionally:

 #define int ui
 #define short ui

as well.  This unfortunately doesn't let me use real "longs", but such is
life.


>     In any case, though, portability is the least of my concerns.

True, but if the compiler's doing something which is compliant with the C
standard but runs contrary to your expectations, you may be expecting
something you shouldn't.

1997\06\13@025934 by ms

flavicon
face
Tjaart van der Walt wrote:
{Quote hidden}

I completely agree!


>The only upgrades we get on MPLAB-C seems to be new random error
>messages.
>
I'm also very, very, very disappointed of the last update


>If anybody knows of a Mchip email address where I can lodge a formal
>complaint about this, please mail it to me.
>
Try to get in contact with Derek P. Carlson (manager for Development
Systems):
spamBeGonederek.carlsonKILLspamspamTakeThisOuTmicrochip.com
EraseMEdcarlson.....spamKILLspamccmail.microchip.com

{Quote hidden}

I would also like to encourage others to complain at Microchip about
their problems with MPLAB-C. Hopefully this helps to either improve
their compiler or make them supporting other more professional compiler
vendors!


Best regards,

Marc Schmaeche

-----------------------------------------------------------------------
        ZENTRUM  FUER  ANGEWANDTE  MIKROELEKTRONIK  UND  NEUE
        TECHNOLOGIEN  DER  BAYERISCHEN  FACHHOCHSCHULEN  E.V.

 Dipl.-Ing. M.Schmaeche     Tel.:   +49 (0)9131 691145
 ZAM-Anwenderzentrum Nbg.   Fax:    +49 (0)9131 691166
 Am Weichselgarten 7        E-Mail: msSTOPspamspamzam.nf.fh-nuernberg.de
 91058 Erlangen, Germany             (Ger/Eng/Spa welcome)
-----------------------------------------------------------------------

1997\06\13@031448 by Andrew Warren

face
flavicon
face
John Payson <PICLISTSTOPspamspamKILLspamMITVMA.MIT.EDU> wrote:

> Is the compiler storing consecutive items in your data structure in
> consecutive words?

   Yes.

> If so, incrementing a pointer should advance it to the next
> address.  If not, it should increment the pointer in such a way as
> to move from one item to the next.

   We're in violent agreement here.

> > The pointer is pointing to 16-bit objects; the size of a (*p) is
> > 16 bits, and each one of these *p's fits in a single 16-bit
> > memory location in the program space.
>
> Certainly each one CAN fit in a single word.  Are you also implying
> that the compiler does, in fact, allocate them that way (while it
> would be silly of the compiler to store values using only the low
> byte of each word, it would not violate the C standard by so doing).

   Yes; the compiler does put each 16-bit value in a single word.

> Fair enough.  And you're saying the handling of int (16-bit)
> quantities doesn't just store half of the number in each of two
> addresses?

   Yes.

> The data type MPC calls an "int" is a "char".  The data type MPC
> calls a "long" is an "int".

   True.

   The type it calls a "char", though, really IS a "char"... So
   that's gotta count for something.

> MPC does not, as far as I know, support [32-bit] "long"'s (the
> only compiler I know that does is HiTech's beta).

   True... But twenty bucks says that by the time HiTech's compiler
   is out of beta, MPC will also directly support 32-bit types.

> Personally, I *NEVER* use the defined type "int" to refer to an
> 8-bit number in CCS.  Instead I *ALWAYS* do:
>
> typedef long ui; /* Unsigned int */
> typedef char ub; /* Unsigned byte */

   Me, too... The real code from which I extracted the example
   code-fragments in my previous message uses "typedef unsigned
   long word" and "typedef unsigned char byte"; I omitted those
   typedefs for brevity.

> > In any case, though, portability is the least of my concerns.
>
> True, but if the compiler's doing something which is compliant with
> the C standard but runs contrary to your expectations, you may be
> expecting something you shouldn't.

   Words to live by.

   In my case, I reach all my program-space memory through access
   functions, so I won't have to change much code when this MPC bug
   is fixed.

   Additionally, I copy all program-space values to buffers in the
   register space before performing any operations on them (and I
   copy them back afterward, of course)... Aside from the speed and
   space benefits, this'll protect me when and if a new version of
   MPC provides a method for accessing program-space memory that's
   less of a kludge than the current "long far pointer" arrangement
   (which is currently the ONLY way that MPC allows access to
   16-bit objects in the program space).

   -Andy

=== Andrew Warren - @spam@fastfwd.....spamspamix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\06\13@033314 by Andrew Warren

face
flavicon
face
Steve Hardy <spamPICLIST.....spam.....MITVMA.MIT.EDU> wrote:

> Perhaps the compiler should allow
>
> long far * p;
>
> *p = value1;
> p += 0.5;       /* ?Que? */
> *p = value2;

   Nice one, Steve.

   Actually, there ARE a couple of workarounds for the problem.
   The original example, which doesn't work because of a bug in
   MPC, was:

       long far *p;        // In MPC, "long" is a 16-bit word.

       p = 0x1000;

       for (x = 10; x != 0; --x)
       {
           *p = 0x1234;
           ++p;            // This doesn't work, since MPC
                           // erroneously increments p by 2.
       }

   WORKAROUND #1:
   --------------

       long far *p;        // In MPC, "long" is a 16-bit word.
       long p_alias @ p;   // p_alias is allocated at the same
                           // address as p.

       p = 0x1000;

       for (x = 10; x != 0; --x)
       {
           *p = 0x1234;
           ++p_alias;      // This works: p_alias is incremented
                           // by one and, since it's allocated at
                           // the same address as p, it indirectly
                           // increments p by one, as well.
       }

   WORKAROUND #2:
   --------------

       long far *p;        // In MPC, "long" is a 16-bit word.

       for (x = 10; x != 0; --x)
       {
           p = (0x1000 - 1) + x;    // This works, but it's slow.
                                    //
                                    // The "-1" term, by the way,
                                    // is necessary because x is
                                    // always in the range [1-10];
                                    // a "for (x=0; x!=10; ++x)"
                                    // would remove the need for the
                                    // "-1" term, but it would force
                                    // the compiler to test for the
                                    // end-of-loop with a comparison
                                    // rather than with a simple
                                    // "DECFSZ x".
           *p = 0x1234;
       }

   -Andy

=== Andrew Warren - fastfwd.....spamix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

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