size of a byte and int?

Watch out, a byte is not always 8 bits. In general, DSPs do not support 8 bit fetch modes like general purpose processors do. Most DSPs will only fetch multiples of the bus width. The TI C54 is not capable of fetching an 8 bit word from memory. It can only fetch (or write) a 16 bit word from (or to) memory. Because of that, the compiler for most DSPs define types so that any type traditionally smaller then the bus width is the the size of the bus width.

On a 32 bit DSP (such as the C3X), a byte, short int, and int are all defined as 32 bits.

Reply to
dan
Loading thread data ...

No, but maybe he's thinking of CHAR_BIT.

Reply to
infobahn

Actually, it's defined in C as "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment". It goes on to say that the bits must be contiguous and that the number of bits are implementation-defined. It must be *at least* 8 bits (CHAR_BIT).

I don't think "word" is defined in C. An "int" must be able to represent any signed number from -32767 to +32767 (inclusive), which means that it must have at least 16 bits.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

Grant Edwards wrote in news:41f69625$0$2355$a1866201 @visi.com:

So, in a bit addressable processor, it's 1 bit? Certainly not in any implementation I've seen.

--
Richard
Reply to
Richard

I forgot to qualify my statement. IIRC, the spec says a byte has to be at least 8 bits. A compiler designer may be allowed to choose a byte size larger than an octet even if memory is adderssable in octets. He'd be a bit daft, IMO, but it may be legal...

--
Grant Edwards                   grante             Yow!  I want to so HAPPY,
                                  at               the VEINS in my neck STAND
 Click to see the full signature
Reply to
Grant Edwards

veering off topic a bit....

Anybody else old enough to have worked on a machine with a 24 bit word and a

6 bit char? The first machine I learned assembler on was like that. With only 6 bits something had to give, and so it couldn't use lower case letters.

Fortunately, they were all scrapped before they got around to implementing C on them.

Peter

Reply to
Peter

To up this, think PDP-10. 36 bits, unless using very special pointers to packed structures of five 7-bit ASCII, with a spare bit in the word. But that doesn't fit too well with C.

Jon

Reply to
Jonathan Kirwan

processor bus.

It's easy to find exceptions to that rule (PDP-8, for instance). As stated in another recent thread, I think a better definition of word is register (GPR) width.

Reply to
toby

The only inconvenience I can think of is dealing with "packed" character arrays. T

Reply to
toby

No, but I did some homework assignments on a machine with a 60 bit word and a 6 bit char.

--
Grant Edwards                   grante             Yow!  BRILL CREAM is
                                  at               CREAM O' WHEAT in another
 Click to see the full signature
Reply to
Grant Edwards

( Or 4 9-bit characters. Doesn't fit the "all bytes are flat and 8 bits" theory either...)

As other pointed out, many DSPs can access memory only one word at a time, and the word width is not necessarily a multiple of 8 bits.

Plus:

  • CDC-6600 mainframes: 60 bit words. You could pack 10 6-bit bytes in each word, but they were not directly addressable. (6 bit was enough for a capital-letters-only reduced character set. FORTRAN and Pascal did not need more.)

  • Early HP-1000 mini-computers, 16 bit words, only word addressable. (I believe the same applies to early Nova minis)

  • PDP-8 minis (and Intersil 6100 copies) - 12 bit words, only word addressable.

I once ported the original Small-C compiler to an HP-2113 mini. (May not be the right model number.) This one was an "advanced model", it had a couple of index registers and could address individual bytes. (No stack pointer, of course) To keep it compatible with existing software, it used the original instruction set with 15 bit addresses for a 32 Kword address space, while a few new instruction took 16 bit addresses for byte operations. In other words, the word at address N contained the two bytes at addresses (N*2) and (N*2)+1. A first attempt to make the compiler use byte addressing was soon discarded. Each memory address or pointer had to be shifted right one bit when accessing words or left untouched for byte access. At the end I made the chars 16 bit wide and used the word addresses consistently across the system.

Was there ever a C compiler for CDC-6600/7??? machines?

Roberto Waltman.

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

No, I started on core memory, but never got realy close to odd wordlength (did some high-level programming with 60 bit words, but don't remember the size of a char - it was academic) until the early

90's on an AD DSP with 24 bit word's. I settled on packed 6 bit chars with a teletype-like upper/lowercase escape sequence in an external display.

Andreas

--
"My name is Dump, Core Dump"
Reply to
Andreas Hadler

Wouldn't work. A byte (in C) must be at least 8 bits wide.

I used to work on a Univac 1100/80, which also had a 36-bit word. Each word held six 6-bit (FIELDATA) characters, or four 9-bit (quarter-word) ASCII characters. The latter would work for C, though pointer arithemetic might be, um, painful.

FWIW, the Univac never had a C compiler when I was working with it. FORTRAN 77, Pascal, PL/I, COBOL, SNOBOL, Lisp, GPSS, Prolog, and many others I'm forgetting now, but no C.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

As I mentioned up-thread: 36-bit word, 6-bit character (most often -- wider character encodings could be used).

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

I worked on a timeshared BASIC for the HP-2114 and HP-2116. I don't recall a

2113, though. My experience was with the 2114, 2116, and 21MX. Subroutines were handled by poking out the first word with the return address and using a jump indirect through it to return to the caller. No stacks, as you say.

Jon

Reply to
Jonathan Kirwan

TI made some very interesting graphics processors about 15 years ago, the 34010 and 34020. All their memory was bit-addressable and they had an excellent C compiler, but with the quirk that the sizeof an 8-bit char was 8, not 1. This was the source of many bugs.

--
Jim McGinnis
Reply to
Jim McGinnis

On Tue, 25 Jan 2005 16:08:07 +0530, "Neo" wrote in comp.arch.embedded:

An example is the TMS320C5402 you are using, or the TMS320F2812 that is one of the processors I am working with these days. They can't provide an exact width int8_t or uint8_t type, because the processor does not provide types with exactly that many bits.

But it can support all of the least n bits types, and fastest n bits types.

Here is a header that I wrote for use with the TI 2812 and Code Composer Studio, it will probably work with your 5402. Try copying it into the compiler include directory, where headers like , , and so on, are.

And as another poster suggested, do a Google search for the N869 draft of the C standard and read up on the integer types and this header.

Copy the text between the lines into an editor and save as stdint.h. =================================================== /*************************************************************************************/ /** \file stdint.h * type definitions and macros for the subset of C99's stdint.h types * that Code Composer Studio for the TMS320C2812 DSP supports * * \date 15-Aug-2003 * * \author Jack Klein * * \b Notes: \n * Note: not all C99 integer types are supported on this * platform, in particular, no 8 bit types at all, and no 64 * bit types *

*************************************************************************************/

#ifndef H_STDINT #define H_STDINT

/* 7.18.1.1 */ /* exact-width signed integer types */ typedef signed int int16_t; typedef signed long int32_t;

/* exact-width unsigned integer types */ typedef unsigned int uint16_t; typedef unsigned long uint32_t;

/* 7.18.1.2 */ /* smallest type of at least n bits */ /* minimum-width signed integer types */ typedef signed int int_least8_t; typedef signed int int_least16_t; typedef signed long int_least32_t;

/* minimum-width unsigned integer types */ typedef unsigned int uint_least8_t; typedef unsigned int uint_least16_t; typedef unsigned long uint_least32_t;

/* 7.18.1.3 */

/* fastest minimum-width signed integer types */ typedef signed int int_fast8_t; typedef signed int int_fast16_t; typedef signed long int_fast32_t;

/* fastest minimum-width unsigned integer types */ typedef unsigned int uint_fast8_t; typedef unsigned int uint_fast16_t; typedef unsigned long uint_fast32_t;

/* 7.18.1.4 integer types capable of holding object pointers */ typedef signed long intptr_t; typedef unsigned long uintptr_t;

/* 7.18.1.5 greatest-width integer types */ typedef signed long intmax_t; typedef unsigned long uintmax_t;

#if !defined(__cplusplus) || defined(__STDC_LIMIT_MACROS)

/* 7.18.2.1 */

/* maximum values of exact-width signed integer types */ #define INT16_MAX 32767 #define INT32_MAX 2147483647L

/* minimum values of exact-width signed integer types */ #define INT16_MIN (-INT16_MAX-1) #define INT32_MIN (-INT32_MAX-1) /* -2147483648 is unsigned

*/

/* maximum values of exact-width unsigned integer types */ #define UINT16_MAX 65535U #define UINT32_MAX 4294967295UL

/* 7.18.2.2 */

/* maximum values of minimum-width signed integer types */ #define INT_LEAST8_MAX 32767 #define INT_LEAST16_MAX 32767 #define INT_LEAST32_MAX 2147483647L

/* minimum values of minimum-width signed integer types */ #define INT_LEAST8_MIN (-INT_LEAST8_MAX-1) #define INT_LEAST16_MIN (-INT_LEAST16_MAX-1) #define INT_LEAST32_MIN (-INT_LEAST32_MAX-1)

/* maximum values of minimum-width unsigned integer types */ #define UINT_LEAST8_MAX 65535U #define UINT_LEAST16_MAX 65535U #define UINT_LEAST32_MAX 4294967295UL

/* 7.18.2.3 */

/* maximum values of fastest minimum-width signed integer types */ #define INT_FAST8_MAX 32767 #define INT_FAST16_MAX 32767 #define INT_FAST32_MAX 2147483647L

/* minimum values of fastest minimum-width signed integer types */ #define INT_FAST8_MIN (-INT_FAST8_MAX-1) #define INT_FAST16_MIN (-INT_FAST16_MAX-1) #define INT_FAST32_MIN (-INT_FAST32_MAX-1)

/* maximum values of fastest minimum-width unsigned integer types

*/ #define UINT_FAST8_MAX 65535U #define UINT_FAST16_MAX 65535U #define UINT_FAST32_MAX 4294967295UL

/* 7.18.2.4 */

/* maximum value of pointer-holding signed integer type */ #define INTPTR_MAX 2147483647L

/* minimum value of pointer-holding signed integer type */ #define INTPTR_MIN (-INTPTR_MAX-1)

/* maximum value of pointer-holding unsigned integer type */ #define UINTPTR_MAX 4294967295UL

/* 7.18.2.5 */

/* maximum value of greatest-width signed integer type */ #define INTMAX_MAX 2147483647L

/* minimum value of greatest-width signed integer type */ #define INTMAX_MIN (-INTMAX_MAX-1)

/* maximum value of greatest-width unsigned integer type */ #define UINTMAX_MAX 4294967295UL

/* 7.18.3 */

/* limits of ptrdiff_t */ #define PTRDIFF_MAX 2147483647L #define PTRDIFF_MIN (-PTRDIFF_MAX-1)

/* limits of sig_atomic_t */ #define SIG_ATOMIC_MAX 2147483647L #define SIG_ATOMIC_MIN (-SIG_ATOMIC_MAX-1)

#endif /* __STDC_LIMIT_MACROS */

#if !defined(__cplusplus) || defined(__STDC_CONSTANT_MACROS)

/* 7.18.4.1 macros for minimum-width integer constants */ #define INT16_C(x) (x) #define INT32_C(x) (x ## l)

#define UINT16_C(x) (x ## u) #define UINT32_C(x) (x ## ul)

/* 7.18.4.2 macros for greatest-width integer constants */ #define INTMAX_C(x) (x ## l) #define UINTMAX_C(x) (x ## ul)

#endif /* __STDC_CONSTANT_MACROS */

#endif /* __stdint_h */

/* end of stdint.h */ ===================================================

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

Jack Klein writes: [...]

Strictly speaking, a C compiler for the TMS320C5402 or TMS320F2812 could provide exact width int8_t and uint8_t types (and make CHAR_BIT==8). It would have to generate extra code to extract and store 8-bit quantities within 16-bit words, and it would need to implement a special pointer format that indicates which octet within a word it points to, as well as the address of the word itself. (This would be similar to the way Cray's C compiler implements CHAR_BIT==8 on 64-bit vector machines.)

This would almost certainly not be worth the effort -- which I suppose is close enough to "can't" for practical purposes.

A related, and actually realistic, point is that C99, which requires

64-bit integers, can be implemented on hardware that doesn't support 64-bit types. The compiler just has to do some extra work to compose 64-bit operations from the available 32-bit operations.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org  
San Diego Supercomputer Center               
 Click to see the full signature
Reply to
Keith Thompson

The only nuisance, in C, is that it is not so easy to guarantee that EOF cannot appear in a char stream. Recall that the char reading routines return an int, which may contain the (positive) value of an unsigned char, or some negative value, defined as EOF.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 Click to see the full signature
Reply to
CBFalconer

The SDS 910 etc. maybe (later the XDS). Scientific Data Systems sold out to Xerox.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 Click to see the full signature
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.