Searching \ for 'Is there a problem with the BYTE CRAFT C?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=there+problem+with
Search entire site for: 'Is there a problem with the BYTE CRAFT C?'.

Truncated match.
PICList Thread
'Is there a problem with the BYTE CRAFT C?'
1997\09\29@120958 by WF AUTOMA‚̀O

flavicon
face
I was observing the machine code created for the "int" type of C
and see that only compare one position of memory, and for a "long int",
only compare two positions of memory! Was this problem resolved?

       My compiler is a 1995 version!

       Miguel.

1997\09\29@141733 by John Payson

picon face
> I was observing the machine code created for the "int" type of C
> and see that only compare one position of memory, and for a "long int",
> only compare two positions of memory! Was this problem resolved?
>
>         My compiler is a 1995 version!

I personally find it offensive that most C compilers for the PIC (the only
exception I know of is HiTech's) regard "int" as an 8-bit type and "long" as
a 16-bit type.  Both of these definitions are clearly contrary to the C stan-
dard (nb: a compiler I use on a different chip has both "char" and "int" as
16-bit types, and sizeof(char)==1, but _that_ is _allowable_ by the C stan-
dard).

Nonetheless, if you use definitions like:

typedef unsigned char ub; /* "Unsigned Byte" */
typedef unsigned long ui; /* "Unsigned Int" */

then these annoyances shouldn't pose too much of a headache.

1997\09\29@144531 by Martin R. Green

picon face
I too find it awkward, but in fact, the length of an int is always platform
dependent, we have just gotten (God, I hate that word) used to 16 bit ints
on Intel platforms.  Normally an int is the same length as the predominant
register length, which on a PIC, is clearly 8 bits.  A 16 bit int is not
part of the C standard.


CIAO - Martin R. Green
spam_OUTelimarTakeThisOuTspambigfoot.com

----------
From:   John Payson[SMTP:.....supercatKILLspamspam@spam@MCS.NET]
Sent:   Monday, September 29, 1997 1:45 PM
To:     PICLISTspamKILLspammitvma.mit.edu
Subject:        Re: Is there a problem with the BYTE CRAFT C?

> I was observing the machine code created for the "int" type of C
> and see that only compare one position of memory, and for a "long int",
> only compare two positions of memory! Was this problem resolved?
>
>         My compiler is a 1995 version!

I personally find it offensive that most C compilers for the PIC (the only
exception I know of is HiTech's) regard "int" as an 8-bit type and "long"
as
a 16-bit type.  Both of these definitions are clearly contrary to the C
stan-
dard (nb: a compiler I use on a different chip has both "char" and "int" as
16-bit types, and sizeof(char)==1, but _that_ is _allowable_ by the C stan-
dard).

Nonetheless, if you use definitions like:

typedef unsigned char ub; /* "Unsigned Byte" */
typedef unsigned long ui; /* "Unsigned Int" */

then these annoyances shouldn't pose too much of a headache.

1997\09\29@152641 by Andy Kunz

flavicon
face
>I personally find it offensive that most C compilers for the PIC (the only
>exception I know of is HiTech's) regard "int" as an 8-bit type and "long" as
>a 16-bit type.  Both of these definitions are clearly contrary to the C stan-

      AAAAAA  MMMMMMM    EEEEEEE  NNNNNN!!!!!!

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\09\29@155502 by Philip Restuccia

flavicon
face
> >I personally find it offensive that most C compilers for the PIC (the only
> >exception I know of is HiTech's) regard "int" as an 8-bit type and "long" as
> >a 16-bit type.  Both of these definitions are clearly contrary to the C stan-
>
>        AAAAAA  MMMMMMM    EEEEEEE  NNNNNN!!!!!!
>
> Andy
>

As someone else has already pointed out, the "C standard" does NOT define any
particular sizes for ANY integral data types; they are platform-dependent.  All
the standard says is (from Section A4.2 in K&R Second Edition):

"Besides the 'char' types, up to three sizes of integer, declared 'short int',
'int',
and 'long int', are available. Plain 'int' objects have the natural size
suggested by
the host machine architecture; the other sizes are provided to meet special
needs.
Longer integers provide at least as much storage as shorter ones, but the
implementation
may make plain integers equivalent to either short integers, or long integers.
The 'int'
types all represent signed values unless specified otherwise."


Terms in single quotes ('') are in bold type in the book.  Thus, since the size
of a PIC's
registers is 8 bits, this would be the "reasonable" size of an 'int', as
dictated by the
above K&R section.  Short's and long's are then up to the compiler writer.

       Philip Restuccia
       .....philip.restucciaKILLspamspam.....peri.com

1997\09\29@162607 by John Payson

picon face
> I too find it awkward, but in fact, the length of an int is always platform
> dependent, we have just gotten (God, I hate that word) used to 16 bit ints
> on Intel platforms.  Normally an int is the same length as the predominant
> register length, which on a PIC, is clearly 8 bits.  A 16 bit int is not
> part of the C standard.

The C standard does not specify the size nor the representation of any
numeric types (e.g. a machine that used 5 10-state tubes to store an INT
would be perfectly fine) except for the following requirements:

[1] A signed char must support values from -127 to 127
[2] A signed int or short must support values from -32767 to 32767
[3] A signed long must support values from -(2^31-1) to (2^31-1)
[4] An unsigned char must support values from 0 to 255
[5] An unsigned int or short must support values from 0 to 65535
[6] An unsigned long must support values from 0 to (2^32-1)
[7] A char [with default signed-ness] must be capable of storing all of the
   characters in the standard C character set as positive integers (this
   latter requirement primarily means that on 8-bit machines which use the
   EBCDIC character set, characters must be unsigned).
[8] sizeof(long) >= sizeof(int) >= sizeof(short) >= sizeof(char) == 1

I think, though I'm not positive, that the following also apply:

[A] Any value that can be stored in a signed type must fit in all "larger"
   signed types.
[B] Any value that can be stored in an unsigned type must fit in all "larger"
   unsigned types.
[C] Any non-negative value that fits in a signed type must fit in the
   corresponding unsigned type.

It's perfectly acceptable for machines to have sizeof(int)==1 if a char
can hold suitably-large values.  For example, on the TI 3205x, ALL inst-
ructions to read/write memory use 16-bit values.  While it's not terribly
difficult to parse out the two halves of a word, the compiler instead
just defines "char" to be a 16-bit word--the same size as a short or an
int.  A bit wasteful of data space, perhaps, but a major saver of time and
codespace.

Unfortunately, the common PIC compiler's notion that an int is 8 bits and
a long is 16 bits fails under tests 2, 3, 5, and 6 above.

1997\09\29@184301 by Alan G. Smith

flavicon
face
Where in the world do you get the requirements from ????

Also, can you  do anything to stop all of your messages from coming across as
attachments?

Thanks,

Alan G. Smith

+---------------------------------------------------------
| Alan G. Smith
| EraseMEagsspam_OUTspamTakeThisOuTpoboxes.com
| http://www.innovatus.com/ags

-----Original Message-----
From: John Payson <supercatspamspam_OUTMCS.NET>
To: @spam@PICLISTKILLspamspamMITVMA.MIT.EDU <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU>
Date: Monday, September 29, 1997 4:27 PM
Subject: Re: Is there a problem with the BYTE CRAFT C?

1997\09\29@190450 by WF AUTOMA‚̀O

flavicon
face
Alan G. Smith wrote:
>
>  Where in the world do you get the requirements from ????
>
> Also, can you  do anything to stop all of your messages from coming across as
>  attachments?
>
> Thanks,
>
> Alan G. Smith
>
> +---------------------------------------------------------
> | Alan G. Smith
> | RemoveMEagsTakeThisOuTspampoboxes.com
> | http://www.innovatus.com/ags
>

????????????????????

:|

1997\09\29@190830 by Andy Kunz

flavicon
face
>above K&R section.  Short's and long's are then up to the compiler writer.

K&R is the problem, then, I suppose.  Most of us have progressed beyond
that stage, and insist upon uniformity.

As I understand it, ANSI and K&R are _NOT_ the same thing.

I, for one, utterly ENJOY being able to test modules on my PC using MS
VC++, then, without changing anything, cut and paste into my HiTech C and
still have functioning code.

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\09\29@200831 by Ross McKenzie

flavicon
face
At 06:40 PM 9/29/97 -0400, Alan G. Smith wrote to John Payson:

>
>Also, can you  do anything to stop all of your messages from coming across as
> attachments?
>
>Thanks,

Alan,

I don't receive any attachments with John's messages. Maybe you have an
errant email reader?


Regards,

Ross McKenzie
Melbourne Australia

to reply by email remove the "nosp*m." text from my email address

1997\09\30@114247 by Kalle Pihlajasaari

flavicon
face
Hi Andy,

> >above K&R section.  Short's and long's are then up to the compiler writer.
>
> K&R is the problem, then, I suppose.  Most of us have progressed beyond
> that stage, and insist upon uniformity.
>
> As I understand it, ANSI and K&R are _NOT_ the same thing.

So it is said.

> I, for one, utterly ENJOY being able to test modules on my PC using MS
> VC++, then, without changing anything, cut and paste into my HiTech C and
> still have functioning code.

Yes, we implemented multidrop communications and the protocol layer
code is linked in by TurboC, C++ or HiTechC with only minor changes
to some hardware dependant header information.

Certainly makes it easier to debug code on a PC and then know that
it works the same on the PIC.

Viva HiTechC :-)

Cheers
--
Kalle Pihlajasaari   spamBeGonekallespamBeGonespamip.co.za   http://www.ip.co.za/ip
Interface Products   P O Box 15775, DOORNFONTEIN, 2028, South Africa
+ 27 (11) 402-7750   Fax: 402-7751    http://www.ip.co.za/people/kalle

DonTronics, Silicon Studio and Wirz Electronics uP Product Dealer

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