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.
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
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
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.
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.
( 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 ]
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.
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.
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.
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.
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 *
/* 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;
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
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
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.