Searching \ for '[PIC:] Microchip C18, or HI-TECH PICC18?' 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: 'Microchip C18, or HI-TECH PICC18?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Microchip C18, or HI-TECH PICC18?'
2004\03\31@035331 by Andre Miller

flavicon
face
Hi,

I was wondering if anyone has any opinions on which of these two compilers
would be 'better'. I know it’s a very objective (or subjective?) question
but right now I just can't decide.

Reading some of the documentation I have made a short list of pro's and
con's. I have been playing with demo versions of both of these for a short
time.

Microchip C18:
- PRO: 24 bit integer datatypes
- PRO: Standard libraries include hardware peripherals (as well as software
implementations)
- CON: No compiler for 14 bit PICs

HI-TECH C18:
- PRO: Also has a 14 bit compiler
- PRO: Much bigger community of users and more source/examples on the web
- CON: No 24 bit integer datatype
- CON: Standard libraries only include ANSI functions, no PIC peripherals,
such as PWM, SPI, ASUART, etc
Currently I'm leaning towards Microchip's compiler mainly due to the fact
that it has standard libraries for hardware peripherals. Does anyone have
any other reasons for picking one or the other?

_____________
       
André Miller        

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu

2004\03\31@070725 by Gerhard Fiedler

picon face
> Reading some of the documentation I have made a short list of pro's and
> con's.
>
> Microchip C18:
> - PRO: Standard libraries include hardware peripherals (as well as software
> implementations)
>
> HI-TECH C18:
> - CON: Standard libraries only include ANSI functions, no PIC peripherals,
> such as PWM, SPI, ASUART, etc
>
> Currently I'm leaning towards Microchip's compiler mainly due to the fact
> that it has standard libraries for hardware peripherals.

I have been using HiTech PICC for a while. I'm not sure libraries for
hardware peripherals are of great help. I find that the exact way I use a
hardware peripheral depends a lot on the particular project: in one case I
poll the UART, in another I receive by interrupt into a long buffer, in
still another I need to watch timing closely and set timeouts. There are
some things that repeat themselves, for sure, but then you write them
easily and quickly. But probably you find them useful as a starting point
if they come with source code -- and if they work. (But then, if they come
with source code, you can use them as a starting point for the HiTech
compiler just the same.)

I can't comment on the Microchip C18, sorry, so no real contribution to
your question.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

2004\03\31@100526 by Andre Miller

flavicon
face
Hi Gerhard,

Thanks for your response. You are right, I am a beginner which is why these
libraries was attractive to me, but as you say, if the sources are there
(and it looks like they are included) I could adapt it for use in any
compiler.

Have you ever found you needed a 24 bit integer datatype and wished PICC had
support for it?
 _____  
André Miller        

{Original Message removed}

2004\03\31@105344 by Mike Harrison

flavicon
face
On Wed, 31 Mar 2004 17:03:47 +0200, you wrote:

>Hi Gerhard,
>
>Thanks for your response. You are right, I am a beginner which is why these
>libraries was attractive to me, but as you say, if the sources are there
>(and it looks like they are included) I could adapt it for use in any
>compiler.
>
>Have you ever found you needed a 24 bit integer datatype and wished PICC had
>support for it?
Frequently. There are many cases where 16 bits isn't quite enough but 32 is wasteful. Probably less of an issue on the PIC18, but on the 16 series, RAM is usually the first thing you run
out of.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2004\03\31@165608 by Andre Miller

flavicon
face
Hmm, do you think that’s a big enough reason to use Microchip C18 instead of
HI-TECH's compiler? I have no yet used PIC's enough to know how often you
would need to use a 24 bit variable, and if you could juse use asm in those
cases you do.

I only noticed HI-TECH PICC lacked 24 bit support when I wanted to implement
Roman Black's one-second timer which needed a 24 bit variable. I guess in
this case I could have used a 32 bit variable, but used inline assembly
instead.

 _____  
André Miller        

{Original Message removed}


'[PIC:] Microchip C18, or HI-TECH PICC18?'
2004\04\01@025209 by William Chops Westfield
face picon face
On Wednesday, Mar 31, 2004, at 00:51 US/Pacific, Andre Miller wrote:
>
> Microchip C18:
> - PRO: 24 bit integer datatypes
>
IMNSHO, you would need to be close to insane to use 24 bit integers in
a C program!

Shudder!
BillW

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

2004\04\01@031530 by Andre Miller

flavicon
face
That’s a big PRO for me then, I am quite close to insane ;-)

 _____  
André Miller        


{Original Message removed}

2004\04\01@063338 by Gerhard Fiedler

picon face
>>Have you ever found you needed a 24 bit integer datatype and wished PICC had
>>support for it?
>
> Frequently. There are many cases where 16 bits isn't quite enough but 32 is wasteful.
> Probably less of an issue on the PIC18, but on the 16 series, RAM is usually the first thing you run
> out of.

For me that's "sometimes". In those cases I use 3 byte structs for storage
and the built-in 32 bit routines for the calculations. I've never had a
case where the additional resources that were needed to do the 32 bit
calculations (temp register, instruction cycles) were a problem.

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

2004\04\01@070941 by Andre Miller

flavicon
face
That’s a great idea. Do you perhaps have some sample code to demonstrate
this? It will be much appreciated :-)

Say for example I want a 24 bit signed variable, using a struct for storage,
how would I:

Decrement that value
Compare it in an 'if' statement?

I can see how I would do it using a pointer to the struct, but wouldn't the
storage for the pointer negate the space saved by using a 3 byte struct?

Sorry if this is a stupid question, I know C (or I think I do), but are
relatively new to PIC's and the need to save as much RAM as possible. Using
C on a PC with 512MB of RAM this is less of an issue ;-).

 _____  
André Miller        

{Original Message removed}

2004\04\01@121026 by Dipperstein, Michael

face picon face
The very last section of Numerical Recipes in C is devoted to arbitrary
precision arithmetic.  Their code is based on stuff Knuth wrote and other
libraries that they provide.  An on-line version of the book can be found at
http://www.nr.com.

You should be able to look at their code a simplify it for the 24-bit functions
that you care about.

If you want to carry less baggage, but do more of your own coding, I have a
library for arbitrary length arrays of bits at:
http://michael.dipperstein.com/bitlibs/

It includes Increment, Decrement, Shift, And, Or, Xor, and Not functions.  I
keep thinking about extending it to include more arithmetic functions.  I have
yet to do it, but your welcome to have a go at it.

The code size could be greatly reduced if only 24-bit arrays were supported.

-Mike

{Original Message removed}

2004\04\02@062630 by Peter L. Peres

picon face
>IMNSHO, you would need to be close to insane to use 24 bit integers in
>a C program!

Why ? What if the word length is 24bits ? What if it's 36bits ? Usually
when there is a C compiler for such a target it has a datatype that
supports the 'native' word width.

Peter

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

2004\04\02@082937 by Gerhard Fiedler

picon face
>> For me that's "sometimes". In those cases I use 3 byte structs for storage
>> and the built-in 32 bit routines for the calculations.
>
> That’s a great idea. Do you perhaps have some sample code to demonstrate
> this? It will be much appreciated :-)
>
> Say for example I want a 24 bit signed variable, using a struct for storage,
> how would I:
>
> Decrement that value
> Compare it in an 'if' statement?

The idea here is that you have limited (static) storage and need only keep
3 byte values, but do _all_ calculations in 4 byte space with temporary
variables. (These are located in a shared memory pool, and unless they are
for some reason on the critical memory path, don't actually take up any
memory.)

You create a 3 byte array or struct as your 24 bit storage type. You create
a function or macro that loads a signed long with this data, treating the
MSB appropriately (0x00 or 0xff, depending on the MSb of the 3rd byte of
the 24 bit var). You then do all arithmetic, comparison etc. with the
signed long temporary variables. After you're done, if you need to store
something, you have another function or macro that stores the 3 LSB of a
signed long in your 24 bit storage type. (It is assumed that the result
will fit into 24 bit, so no checking is done. That should be done somewhere
else if necessary -- you might have another function or macro for this.)

Sorry, no sample code available. But if you try something and have problems
and post your problems, I'd be happy to help.

ge

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

2004\04\02@084447 by Mike Harrison

flavicon
face
On Fri, 2 Apr 2004 13:14:41 +0200, you wrote:

>>IMNSHO, you would need to be close to insane to use 24 bit integers in
>>a C program!

Then you have obviously not done a serious C program on a resource-limited 8 bit processor like the
PIC.

Doing thing like applying scaling/calibration  factors to 12-16 bit data requires >16 bit maths, but
rarely needs >24.
--
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

2004\04\02@085807 by Andre Miller

flavicon
face
Thanks, that’s enough to get me going.

I was thinking about using a long pointer to the 3 byte struct, but this
will not work. The 4th byte in memory will be 'undefined' and will influence
the value and sign (if its signed).
So if I understand you correctly, the static variable can be a 3 byte array,
a three byte struct, or three separate char variables.

Then when I use them in a function, I declare a local 32 bit variable, and
copy these bytes into the local variable, 0x00 if MSB is clear and 0xFF if
MSB is set gets copied to the upper 8 bits.

Afterwards I just copy the 3 lower bytes out again.

Sounds easy enough :-)

 _____  
André Miller        


{Original Message removed}

2004\04\02@093737 by Sergio Masci

picon face
----- Original Message -----
From: Peter L. Peres <.....plpKILLspamspam.....ACTCOM.CO.IL>
To: <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Friday, April 02, 2004 12:14 PM
Subject: Re: [PIC:] Microchip C18, or HI-TECH PICC18?


> >IMNSHO, you would need to be close to insane to use 24 bit integers in
> >a C program!
>
> Why ? What if the word length is 24bits ? What if it's 36bits ? Usually
> when there is a C compiler for such a target it has a datatype that
> supports the 'native' word width.
>
> Peter

Yes, and that type is normally called "int"

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

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

2004\04\02@094812 by Spehro Pefhany

picon face
At 03:38 PM 4/2/2004 +0100, you wrote:
>----- Original Message -----
>From: Peter L. Peres <plpspamspam_OUTACTCOM.CO.IL>
>To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
>Sent: Friday, April 02, 2004 12:14 PM
>Subject: Re: [PIC:] Microchip C18, or HI-TECH PICC18?
>
>
> > >IMNSHO, you would need to be close to insane to use 24 bit integers in
> > >a C program!
> >
> > Why ? What if the word length is 24bits ? What if it's 36bits ? Usually
> > when there is a C compiler for such a target it has a datatype that
> > supports the 'native' word width.
> >
> > Peter
>
>Yes, and that type is normally called "int"

Provided that said native word width can represent numbers from
-32767 to +32767 inclusive, at a *minimum*.

Otherwise it would be a rather serious noncompliance with the C standard.

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 list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\02@095852 by hael Rigby-Jones

picon face
{Quote hidden}

The CCS C compiler has 8 bit int's.  Sounds about typical! :-)

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.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
postmasterEraseMEspam.....bookham.com.

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

2004\04\02@102419 by Andre Miller

flavicon
face
The reason this question came up, was my comparison between MC18 and PICC18
:-)
Microchips C18 compiler has:

Char - 8 bits
Unsigned char - 8 bits
Int - 16 bits
Unsigned int - 16 bits
Short - 16 bits
Unsigned short - 16 bits
Short long - 24 bits
Unsigned short long - 24 bits
Long - 32 bits
Unsigned long - 32 bits

The PICC18 compiler only has 8, 16 and 32 bit data types.

 _____  
André Miller        
       

{Original Message removed}

2004\04\02@103008 by Sergio Masci

picon face
> > > Why ? What if the word length is 24bits ? What if it's 36bits ? Usually
> > > when there is a C compiler for such a target it has a datatype that
> > > supports the 'native' word width.
> > >
> > > Peter
> >
> >Yes, and that type is normally called "int"
>
> Provided that said native word width can represent numbers from
> -32767 to +32767 inclusive, at a *minimum*.
>
> Otherwise it would be a rather serious noncompliance with the C standard.
>

Which standard is this?

Last time I looked "int" was supposed to be the native word size of the machine.
The idea was that by using variables of type "int" as the default you got
optimal performance from the hardware. Please don't tell me a committee has
re-defined it.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

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

2004\04\02@103628 by D. Jay Newman

flavicon
face
> > Provided that said native word width can represent numbers from
> > -32767 to +32767 inclusive, at a *minimum*.
> >
> > Otherwise it would be a rather serious noncompliance with the C standard.
>
> Which standard is this?

The ANSI C standard.

> Last time I looked "int" was supposed to be the native word size of the machine.
> The idea was that by using variables of type "int" as the default you got
> optimal performance from the hardware. Please don't tell me a committee has
> re-defined it.

As computers became bigger and C became more portable, the standards had
to accept this. Since almost all processors can use 2-byte integers this
was defined as the minimum size of an "int". The implementer of the
compiler may use a greater range if that is more natural for the machine.

The trouble with letting an "int" go down is just a single byte is that
it breaks many programs that follow the standard.

Since embedded programs tend to be non-standard, there is nothing wrong
with the compiler defining an "int8" byte or a "byte" type.
--
D. Jay Newman           !
EraseMEjayspamsprucegrove.com     ! Xander: Giles, don't make cave-slayer unhappy.
http://enerd.ws/robots/ !

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

2004\04\02@112922 by Bob Ammerman

picon face
Standard C has always required +/- 32767 minimum range on ints.

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Sergio Masci" <RemoveMEsmplEraseMEspamEraseMENTLWORLD.COM>
To: <RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU>
Sent: Friday, April 02, 2004 10:30 AM
Subject: Re: [PIC:] Microchip C18, or HI-TECH PICC18?


> > > > Why ? What if the word length is 24bits ? What if it's 36bits ?
Usually
{Quote hidden}

standard.
> >
>
> Which standard is this?
>
> Last time I looked "int" was supposed to be the native word size of the
machine.
> The idea was that by using variables of type "int" as the default you got
> optimal performance from the hardware. Please don't tell me a committee
has
> re-defined it.
>
> Regards
> Sergio Masci
>
> http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC
compiler
>
> --
> 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
>

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

2004\04\02@113130 by Ken Pergola

flavicon
face
> Provided that said native word width can represent numbers from
> -32767 to +32767 inclusive, at a *minimum*.


The original poster meant to write: -32768 to +32767.

I'm sure the original poster just made a Freudian slip -- I don't mean to be
a nit-picker or put anyone on the spot -- that is not my intention, so
please don't take any offense. I just wanted to make this correction so that
people who don't know about this, know the correct range and do not
propagate this error that I see all too often.

Even though it's an "off by one error", programming is all about exactness
and it's just a pet-peeve of mine. I have a C++ textbook that totally
botches the maximum negative numbers on integer types. Some readers who do
not know any better just swallow this as fact -- that's the only reason why
I posted this correction.


Regards,

Ken Pergola

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

2004\04\02@114901 by piclist

flavicon
face
On Fri, 2 Apr 2004, Sergio Masci wrote:

> Last time I looked "int" was supposed to be the native word size of the machine.
> The idea was that by using variables of type "int" as the default you got
> optimal performance from the hardware. Please don't tell me a committee has
> re-defined it.

This is what the C90 and C99 standards say:

"A plain int object has the natural size suggested by the architecture
of the execution environment (large enough to contain any value in the
range INT_MIN to INT_MAX as defined in the header <limits.h>)."

And the definitions in limits.h are:

INT_MIN -32767     // -(2**15 - 1)
INT_MAX +32767     // 2**15 - 1

--
John W. Temples, III

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

2004\04\02@115105 by piclist

flavicon
face
On Fri, 2 Apr 2004, Ken Pergola wrote:

> > Provided that said native word width can represent numbers from
> > -32767 to +32767 inclusive, at a *minimum*.
>
> The original poster meant to write: -32768 to +32767.

The original poster was correct.

--
John W. Temples, III

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

2004\04\02@115522 by Ken Pergola

flavicon
face
Hi Andre,

Before you make your choice, you might want to look at the comparison of the
two C compilers from the strict ANSI C compliance angle (if that is indeed
important to you). This will require some time and careful investigation on
your part, but I believe it is time well spent -- before you spend your
hard-earned cash.

Best regards,

Ken Pergola

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

2004\04\02@122429 by Mike Harrison

flavicon
face
On Fri, 2 Apr 2004 10:53:44 -0500, you wrote:

>Hi Andre,
>
>Before you make your choice, you might want to look at the comparison of the
>two C compilers from the strict ANSI C compliance angle (if that is indeed
>important to you). This will require some time and careful investigation on
>your part, but I believe it is time well spent -- before you spend your
>hard-earned cash.
>
>Best regards,
>
>Ken Pergola

On a resource-limited micro, reliability, code and ram efficiency, and good access to hardware is
more important than strict ANSI compliance. I would put compliance pretty low on the list of
priorities

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

2004\04\02@123050 by Ken Pergola

flavicon
face
Mike Harrison wrote:

> On a resource-limited micro, reliability, code and ram
> efficiency, and good access to hardware is
> more important than strict ANSI compliance. I would put
> compliance pretty low on the list of
> priorities


Hi Mike,

But it all comes down to what is important to him (the original poster) and
his priorities.

That's why I said to him:

"...from the strict ANSI C compliance angle (if that is indeed important to
you)."

He's the one that will have to live with the decision he makes. I was just
giving him something to consider.

Best regards,

Ken Pergola

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

2004\04\02@131220 by Sergio Masci

picon face
----- Original Message -----
From: <RemoveMEpiclistTakeThisOuTspamspamXARGS.COM>
To: <EraseMEPICLISTspamspamspamBeGoneMITVMA.MIT.EDU>
Sent: Friday, April 02, 2004 5:48 PM
Subject: Re: [PIC:] Microchip C18, or HI-TECH PICC18?


> On Fri, 2 Apr 2004, Sergio Masci wrote:
>
> > Last time I looked "int" was supposed to be the native word size of the
machine.
{Quote hidden}

Thanks for the pointer. I note from the definition above that the standard tries
to take into account one's complement negative numbers, so does it explicitly
define how -0 (minus zero) should be handled?

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

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

2004\04\02@132428 by Wouter van Ooijen

face picon face
> Thanks for the pointer. I note from the definition above that
> the standard tries
> to take into account one's complement negative numbers, so
> does it explicitly
> define how -0 (minus zero) should be handled?

AFAIK -0 == 0, no distinction. One's complement hardware is allowed, but
a distinct -0 is not.

Wouter van Ooijen

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

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

2004\04\02@132845 by Ken Pergola

flavicon
face
John W. Temples wrote:

> The original poster was correct.

Hi John,

Thanks for your note John, and my apologies to the original poster if I was
presumptuous in my post -- I took it to mean that a 16-bit signed integer
can *only* take on the values of -32767 to +32767 inclusive, but with the C
programming language aside, the decimal range of a signed (2s compliment)
16-bit integer is actually -32768 to +32767.

There is one thing about <limits.h> from "The C Programming Language"
(second edition) by Brian Kernighan and Dennis Ritchie that is confusing to
me (I'm not sure if that edition came out before the C90 standard):

"The values are acceptable minimum magnitudes; larger values may be used."

.
 .
 .
INT_MAX  +32767
INT_MIN  -32767
 .
 .
 .

Does "larger values may be used" mean that the following is legal?:

    signed int Number = -32768;


Do these defined constants mean that you can't use the *full* range of a
16-bit signed number in S16 integer types in your C programs?
I honestly don't understand why they did not use -32768 for INT_MIN -- this
appears lazy to me. I must be missing something obvious.
Why are they not using the full range in the defined constants?



HI-TECH for example defines:

#define INT_MAX         32767           /* max for int */
#define INT_MIN         (int)-32768     /* min for int */


Does this mean that HI-TECH is not ANSI C compliant?


Thanks for any clarification. I appreciate your time.


Best regards,

Ken Pergola

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

2004\04\02@133715 by Mike Harrison

flavicon
face
On Fri, 2 Apr 2004 13:28:35 -0500, you wrote:

{Quote hidden}

No, because it says "larger<magnitude> values can be used", so -32768 is fine, -32766 is not.
Maybe they were thinking that -32768 could be used as a special value in some systems ?

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

2004\04\02@133923 by piclist

flavicon
face
On Fri, 2 Apr 2004, Sergio Masci wrote:

> I note from the definition above that the standard tries
> to take into account one's complement negative numbers, so does it explicitly
> define how -0 (minus zero) should be handled?

I can't see where C90 mentions it.  C99 says that it "is
implementation-defined [...] whether the value with sign bit 1 and all
value bits zero ([ for sign and magnitude or two's complement ]), or
with sign bit and all value bits 1 (for one's complement), is a trap
representation or a normal value."

--
John W. Temples, III

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

2004\04\02@134335 by piclist

flavicon
face
On Fri, 2 Apr 2004, Ken Pergola wrote:

> There is one thing about <limits.h> from "The C Programming Language"
> (second edition) by Brian Kernighan and Dennis Ritchie that is confusing to
> me (I'm not sure if that edition came out before the C90 standard):

It did, but I don't think anything changed related to INT_MIN/INT_MAX.

> "The values are acceptable minimum magnitudes; larger values may be used."
>   .
> INT_MAX  +32767
> INT_MIN  -32767
>
> Does "larger values may be used" mean that the following is legal?:
>
>      signed int Number = -32768;

The standard says, "Their implementation-defined values shall be equal
or greater in magnitude (absolute value) to those shown, with the same
sign."  So I would say that your code is legal, if the implementation
permits -32768 in an int.

And of course, an "int" is 32 bits on many platforms.

> Do these defined constants mean that you can't use the *full* range of a
> 16-bit signed number in S16 integer types in your C programs?
> I honestly don't understand why they did not use -32768 for INT_MIN -- this
> appears lazy to me. I must be missing something obvious.
> Why are they not using the full range in the defined constants?

I'm guessing there is hardware that does not permit a 0x8000 to be a
signed value, i.e., it would cause an exception to be raised.

> HI-TECH for example defines:
>
> #define INT_MAX         32767           /* max for int */
> #define INT_MIN         (int)-32768     /* min for int */
>
> Does this mean that HI-TECH is not ANSI C compliant?

That looks legal to me.

--
John W. Temples, III

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

2004\04\02@134921 by piclist

flavicon
face
On Fri, 2 Apr 2004, Wouter van Ooijen wrote:

> AFAIK -0 == 0, no distinction. One's complement hardware is allowed, but
> a distinct -0 is not.

C99 specifically allows negative zero on one's complement and sign and
magnitude hardware.

"If the implementation supports negative zeros, they shall be generated
only by:

  the &, |, ^, ~, <<, and >> operators with arguments that produce
such a value;

  the +, -, *, /, and % operators where one argument is a negative
zero and the result is zero:

  compound assignment operators based on the above cases.

It is unspecified whether these cases actually generate a negative
zero or a normal zero, and whether a negative zero becomes a normal
zero when stored in an object."

--
John W. Temples, III

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

2004\04\02@135337 by Ken Pergola

flavicon
face
Re: John Temples' response...

Hi John,

Thanks very much for spending the time to answer my questions -- I
definitely appreciate it.
Also thanks to Mike Harrison, and all others as well.

Best regards,

Ken Pergola

P.S. I apologize to everyone for drifting this thread off-topic.

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

2004\04\02@143044 by Spehro Pefhany

picon face
At 01:28 PM 4/2/2004 -0500, you wrote:

>Do these defined constants mean that you can't use the *full* range of a
>16-bit signed number in S16 integer types in your C programs?
>I honestly don't understand why they did not use -32768 for INT_MIN -- this
>appears lazy to me. I must be missing something obvious.
>Why are they not using the full range in the defined constants?

Because not all systems will use 2's complement math with those 16 bits.
Forcing -32768 to be acceptable would break some existing systems and
would dictate the internal representation, something the standard tries hard
not to do.

>HI-TECH for example defines:
>
>#define INT_MAX         32767           /* max for int */
>#define INT_MIN         (int)-32768     /* min for int */
>
>
>Does this mean that HI-TECH is not ANSI C compliant?

No, because those limits *include* the minimum range specified in the
standard.
You can make it larger, but not smaller and still be compliant. For example,
a machine with a 32-bit native word size using 2's complement
representation might well choose to use INT_MAX 2^31-1 and INT_MIN -2^31.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
RemoveMEspeffKILLspamspaminterlog.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 list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\02@145955 by William Chops Westfield

face picon face
On Friday, Apr 2, 2004, at 03:14 US/Pacific, Peter L. Peres wrote:

>> IMNSHO, you would need to be close to insane to use 24 bit integers in
>> a C program!
>
> Why ? What if the word length is 24bits ? What if it's 36bits ? Usually
> when there is a C compiler for such a target it has a datatype that
> supports the 'native' word width.
>
Using an "int" that happens to be 24 bits (or some other odd number) is
fine, but explicitly picking a 24bit datasize because 16 is too small,
and 32 is too big, is so non-portable that it would be a bad idea.
(Now, you can probably do things so that the 24bit quantities are
32 bits in compilers that don't have 24bit integers and have the best
of both worlds, but it will take some care...)

For me, portability is a major reason for using C.  Deciding to use
features that are specific to a particular compiler should be done with
great care.  If you're JUST using C to get code written faster, you can
be less particular, of course.

BillW

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

2004\04\02@151244 by William Chops Westfield

face picon face
On Friday, Apr 2, 2004, at 08:24 US/Pacific, Ken Pergola wrote:

>
>> Provided that said native word width can represent numbers from
>> -32767 to +32767 inclusive, at a *minimum*.
>
>
> The original poster meant to write: -32768 to +32767.
>
Really?  The C standard dissallows ones complement machines?

-32768 to +32767 IS of course "AT LEAST ..."

BillW

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

2004\04\02@151413 by Mike Harrison

flavicon
face
On Fri, 2 Apr 2004 11:58:11 -0800, you wrote:

>On Friday, Apr 2, 2004, at 03:14 US/Pacific, Peter L. Peres wrote:
>
>>> IMNSHO, you would need to be close to insane to use 24 bit integers in
>>> a C program!
>>
>> Why ? What if the word length is 24bits ? What if it's 36bits ? Usually
>> when there is a C compiler for such a target it has a datatype that
>> supports the 'native' word width.
>>
>Using an "int" that happens to be 24 bits (or some other odd number) is
>fine, but explicitly picking a 24bit datasize because 16 is too small,
>and 32 is too big, is so non-portable that it would be a bad idea.
>(Now, you can probably do things so that the 24bit quantities are
>32 bits in compilers that don't have 24bit integers and have the best
>of both worlds, but it will take some care...)

But the reason for using 'just right' sizes would be to preserve resources where they are limited -
in this environment, fitting the code into the part is usually way more important than portability.
Embedded apps on the PIC scale are very rarely ported to a different processor or compiler - I would
happily sacrifice portability if it meant I could squeeze more code in.
--
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

2004\04\02@152451 by Bob Ammerman

picon face
The standard REQUIRES an int to be able to represent the values -32767
through +32767

The standard PERMITS an int to be able to represent other values.

The standard PERMITS (requires?) the implementation to state its range of
valid values of int as INT_MIN/INT_MAX in limits.h.

Bob Ammerman
RAm Systems


{Original Message removed}

2004\04\02@152833 by piclist

flavicon
face
On Fri, 2 Apr 2004, Bob Ammerman wrote:

> The standard PERMITS (requires?) the implementation to state its range of
> valid values of int as INT_MIN/INT_MAX in limits.h.

Requires.

--
John W. Temples, III

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

2004\04\02@155752 by William Chops Westfield

face picon face
On Friday, Apr 2, 2004, at 12:13 US/Pacific, Mike Harrison wrote:

> But the reason for using 'just right' sizes would be to preserve
> resources where they are limited - in this environment, fitting the
> code into the part is usually way more important than portability.

Maybe.  If you have a lot of 24bit variables, perhaps.  The application
that can't tolerate the extra byte on the OCCASIONAL large integer is
scarily close to needing a bigger processor (fortunately, bigger
processors are pretty easy to come by these days.)  Code so close to
the edge that I don't think it will continue to fit in the same chip
over the product (or development) life time is bad (but almost all of
my experience is on systems with upgradable firmware/software, where
the customer expects to be able to upgrade several times before the
product becomes useless.)

> Embedded apps on the PIC scale are very rarely ported to a different
> processor or compiler...

I believe it's rare to port PIC-scale embedded applications to a
different processor.  Different compiler doesn't seem that unlikely,
though...  I dunno.  We have "maybe we shouldn't have used that
feature" issues just across different versions of a single compiler.
(Again, that's in an environment where the same SW has been being
updated for 15 years; not quite the average PIC product.)  And you
should see the tool group people start cursing when they start
considering what it would take to get us using a potentially better
compiler...

BillW

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

2004\04\02@160549 by Spehro Pefhany

picon face
At 12:56 PM 4/2/2004 -0800, you wrote:


>I believe it's rare to port PIC-scale embedded applications to a
>different processor.

That is probably true at an application level, however, I've ported many C
routines between disparate processor families such as the PIC16/18,
8051 and MSP430. The further you get from bit twiddling and peripheral-
setting (most of which is EXTREMELY processor-dependent, sometimes even
within a family), the more useful it tends to be.

I have one now that I originally wrote in 8051 assembly that would be
ideal to port to the PIC for a new application (probably 75-80% commonality)
if it had only been written in C to begin with.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffSTOPspamspamspam_OUTinterlog.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 list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\02@164816 by Edward Gisske

flavicon
face
Spehro,

You might try porting it to the pic via the parallax instruction set. Tech
Tools has a free downloadable assembler (CVASM6.2) that you can get at their
web site. It is an 8051-like language that can be used to port 8051 code to
the pic with not-a-lot of tweaking. I have converted quite a number of my
old favorite 8051 routines with this hack. The assembler also reads
pic-standard mnemonics, with a couple of syntax exceptions.

http://tech-tools.com/d_cvw.htm

Edward Gisske, P.E.
Gisske Engineering
608-523-1900
spamBeGonegisskeSTOPspamspamEraseMEoffex.com


{Original Message removed}

2004\04\02@191630 by Ken Pergola

flavicon
face
Spehro Pefhany wrote:

> Because not all systems will use 2's complement math with those 16 bits.
> Forcing -32768 to be acceptable would break some existing systems and
> would dictate the internal representation, something the standard
> tries hard
> not to do.

Thanks Spehro and I apologize. Clearly I was in error because I was *only*
thinking in terms of two's complement representation.

Best regards,

Ken Pergola

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

2004\04\02@193952 by Sergio Masci

picon face
----- Original Message -----
From: <KILLspampiclistspamBeGonespamXARGS.COM>
To: <EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU>
Sent: Friday, April 02, 2004 7:49 PM
Subject: Re: [PIC:] Microchip C18, or HI-TECH PICC18?


{Quote hidden}

Thanks for posting this. I haven't had such a good laugh in ages.

<rant>
Why bother pissing about insisting that an "int" be capable of holding a value
in the range INT_MIN to INT_MAX if you are not going to require that 0 actually
be 0. Sorry but if I write 0 to a port I expect all the bits to cleared no mater
how the 0 was computed.
</rant>

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

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

2004\04\03@192919 by Spehro Pefhany

picon face
At 04:30 PM 4/2/2004 +0100, you wrote:
> > > > Why ? What if the word length is 24bits ? What if it's 36bits ? Usually
> > > > when there is a C compiler for such a target it has a datatype that
> > > > supports the 'native' word width.
> > > >
> > > > Peter
> > >
> > >Yes, and that type is normally called "int"
> >
> > Provided that said native word width can represent numbers from
> > -32767 to +32767 inclusive, at a *minimum*.
> >
> > Otherwise it would be a rather serious noncompliance with the C standard.
> >
>
>Which standard is this?

ANSI ISO/IEC 9899:1999 (E) , of course.

Here is the section on the limits.h header:

The contents of the header <limits.h> are given below, in alphabetical
order. The
minimum magnitudes shown shall be replaced by implementation-defined magnitudes
with the same sign. The values shall all be constant expressions suitable
for use in #if
preprocessing directives. The components are described further in 5.2.4.2.1.
#define CHAR_BIT 8
#define CHAR_MAX UCHAR_MAX or SCHAR_MAX
#define CHAR_MIN 0 or SCHAR_MIN
#define INT_MAX +32767
#define INT_MIN -32767
#define LONG_MAX +2147483647
#define LONG_MIN -2147483647
#define LLONG_MAX +9223372036854775807
#define LLONG_MIN -9223372036854775807
#define MB_LEN_MAX 1
#define SCHAR_MAX +127
#define SCHAR_MIN -127
#define SHRT_MAX +32767
#define SHRT_MIN -32767
#define UCHAR_MAX 255
#define USHRT_MAX 65535
#define UINT_MAX 65535
#define ULONG_MAX 4294967295
#define ULLONG_MAX 18446744073709551615


>Last time I looked "int" was supposed to be the native word size of the
>machine.
>The idea was that by using variables of type "int" as the default you got
>optimal performance from the hardware. Please don't tell me a committee has
>re-defined it.

Perfectly reasonable, IMO, from a portability point of view, to set minimum
expectations for the range of data types. Compilers for bigger machines are
free to have 32 or 64 bit ints.

You could try using one of the types such as int8_t or (better) int_least8_t,
int_fast8_t etc.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
@spam@speff@spam@spamspam_OUTinterlog.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\04\03@200324 by piclist

flavicon
face
On Fri, 2 Apr 2004, Spehro Pefhany wrote:

> >Which standard is this?
>
> ANSI ISO/IEC 9899:1999 (E) , of course.

Unfortunately, there are no compilers for the PIC which comply with
that standard.  But INT_MIN/INT_MAX are defined in the 9899:1990 spec,
upon which the Hi-Tech and C18 compilers are based.

> You could try using one of the types such as int8_t or (better) int_least8_t,
> int_fast8_t etc.

Which are new in 9899:1999, and aren't predefined on any PIC C
compiler that I'm aware of.

--
John W. Temples, III

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

2004\04\03@202022 by Spehro Pefhany

picon face
At 05:01 PM 4/3/2004 -0800, you wrote:
>On Fri, 2 Apr 2004, Spehro Pefhany wrote:
>
> > You could try using one of the types such as int8_t or (better)
> int_least8_t,
> > int_fast8_t etc.
>
>Which are new in 9899:1999, and aren't predefined on any PIC C
>compiler that I'm aware of.

No, but you can define them and it should be compatible with future
compilers.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spamBeGonespeffspamKILLspaminterlog.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\04\05@071136 by Gerhard Fiedler

picon face
> I was thinking about using a long pointer to the 3 byte struct, but this
> will not work. The 4th byte in memory will be 'undefined' and will influence
> the value and sign (if its signed).

This is correct. Since you don't have 4 bytes in memory, the pointer
wouldn't point to anything valid.

> So if I understand you correctly, the static variable can be a 3 byte array,
> a three byte struct, or three separate char variables.

Correct. (However, I wouldn't advise the latter option, from a readability
and maintainability point of view.)

> Then when I use them in a function, I declare a local 32 bit variable, and
> copy these bytes into the local variable, 0x00 if MSB is clear and 0xFF if
> MSB is set gets copied to the upper 8 bits.
>
> Afterwards I just copy the 3 lower bytes out again.

That's it! :)

ge

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspam_OUTspammitvma.mit.edu

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