G
Grant Edwards
Common sense is often wrong. As yours seems to be in this
case. I've worked on architectures where a byte (a-la "C") was
32 bits.
The OP is asking about C. In C, 'byte' has a very specific
definition.
Common sense is often wrong. As yours seems to be in this
case. I've worked on architectures where a byte (a-la "C") was
32 bits.
The OP is asking about C. In C, 'byte' has a very specific
definition.
G
Grant Edwards
I disagree. I imagine that these days it's mostly in embedded
work where C programmers run across bytes that aren't 8-bits
wide.
Yes it does. The only current architectures I'm aware of that
have non-8-bit bytes are used in embedded systems.
M
Mark A. Odell
(e-mail address removed) (42Bastian Schick) wrote in
No, but maybe you're thinking of CHAR_BITS?
No, but maybe you're thinking of CHAR_BITS?
M
Mark A. Odell
(e-mail address removed) (42Bastian Schick) wrote in
Leading underscores are for the implementation, not application programs.
Leading underscores are for the implementation, not application programs.
I
infobahn
Mark A. Odell said:
No, but maybe he's thinking of CHAR_BIT.
K
Keith Thompson
Hans-Bernhard Broeker said:
Quibble: it's CHAR_BIT, not CHAR_BITS.
Given CHAR_BIT == 13, the minimum allowable sizes are:
sizeof(short) >= 2 /* 26 bits */
sizeof(int) >= 2 /* 26 bits */
sizeof(long) >= 3 /* 39 bits */
short and int must have at least 16 bits that aren't padding bits;
long must have at least 32 non-padding bits. int must be at least as
wide as short, and long must be at least as wide as int, but given
padding bits width and size aren't necessarily directly related. An
even more perverse implementation could have:
sizeof(short) == 3
sizeof(int) == 2
I can't imagine any good reason to do this, but the standard allows
it.
J
Jonathan Kirwan
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
T
toby
David said:
The only inconvenience I can think of is dealing with "packed"
character arrays.
T
R
Roberto Waltman
( 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 ]
D
Dave Hansen
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
J
Jonathan Kirwan
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
J
Jack Klein
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 <stdint.h> 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
<stdio.h>, <string.h>, 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 */
===================================================
J
Jack Klein
I disagree that this is not relevant to comp.arch.embedded. Many, in
fact most, C programmers are totally unaware of what the C standard
allows in terms of integer and floating point types. It is most
commonly in embedded only platforms, like 16-bit, 24-bit (Mot 56K),
and 32-bit DSPs that this is even a concern these days.
Yes, as others elsewhere in the thread point out, there were other,
and sometimes stranger, architectures in days gone by, but in practice
anyone who hasn't come across such a system by now will almost
certainly only ever come across this issue in the future if they
program a DSP or oddball SOC, and that is only going to happen in
embedded systems.
I think that letting a little light shine in on embedded programmers
is topical here.
K
Keith Thompson
Jack Klein said:
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.
C
CBFalconer
toby said:
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.
4
42Bastian Schick
Maybe, or even sure, but if you read MBytes, KBytes etc. do you
honestly thing in 32-bit bytes ?
Didn't know that C defines the term byte.
4
42Bastian Schick
Eh, what do you mean by implementation ?
And what is an application in this regard ?
Is a TCP/IP stack an application in this sense ?
I am confused !
M
Michael Mair
R
Richard Bos
When I read megabytes et cetera, I do so in a hard drive spec, not in a
C programming context. When programming, I don't use megabytes, I use
precise numbers, and precise sizes.
(Unhinted crossposts are evil.)
Richard
P
pete
42Bastian said:
A C implementation is whatever it takes to translate and execute
a C program.
If you have a compiler or a cross compiler,
then that would be part of your implementation.