«

"Dik T. Winter" <> writes:
> In article <. com>
> "user923005" <> writes:
[snip]
> > How about where sizeof int is not evenly divisible by sizeof char?
> > CDC Cyber UTexas C compiler
[snip]
> That is possible (but gives problems with floats that are also 60 bits).
> But on those machines it is much more reasonable to have 48 bit ints
> with the remaining 16 bits (possible) garbage. But integer arithmetic
> on those machines had quite a few strange points. That is, I could
> easily construct examples where:
> (a + a) * 2 != a + a + a + a
> in integer arithmetic, even when a < 2**48.

I'm having trouble imagining that that's anything other than WRONG
(assuming there's no overflow).

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson wrote:
> "Dik T. Winter" <> writes:
> > In article <. com>
> > "user923005" <> writes:
> [snip]
> > > How about where sizeof int is not evenly divisible by sizeof char?
> > > CDC Cyber UTexas C compiler
> [snip]
> > That is possible (but gives problems with floats that are also 60 bits).
> > But on those machines it is much more reasonable to have 48 bit ints
> > with the remaining 16 bits (possible) garbage. But integer arithmetic
> > on those machines had quite a few strange points. That is, I could
> > easily construct examples where:
> > (a + a) * 2 != a + a + a + a
> > in integer arithmetic, even when a < 2**48.
>
> I'm having trouble imagining that that's anything other than WRONG
> (assuming there's no overflow).

A bit of unwrapping of this URL will be wanted. Read from here down:
http://groups.google.com/group/comp....3da52104d0ae03

> --
> Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
> We must do something. This is something. Therefore, we must do this.

"user923005" <> writes:
> Keith Thompson wrote:
>> "Dik T. Winter" <> writes:
>> > In article <. com>
>> > "user923005" <> writes:
>> [snip]
>> > > How about where sizeof int is not evenly divisible by sizeof char?
>> > > CDC Cyber UTexas C compiler
>> [snip]
>> > That is possible (but gives problems with floats that are also 60 bits).
>> > But on those machines it is much more reasonable to have 48 bit ints
>> > with the remaining 16 bits (possible) garbage. But integer arithmetic
>> > on those machines had quite a few strange points. That is, I could
>> > easily construct examples where:
>> > (a + a) * 2 != a + a + a + a
>> > in integer arithmetic, even when a < 2**48.
>>
>> I'm having trouble imagining that that's anything other than WRONG
>> (assuming there's no overflow).
>
> A bit of unwrapping of this URL will be wanted. Read from here down:
> http://groups.google.com/group/comp....3da52104d0ae03

Or <http://preview.tinyurl.com/ykcnee>.

But that thread talks about floating-point arithmetic.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson <kst-> writes:

> "user923005" <> writes:
> > Spiros Bousbouras wrote:
> >> Do you have an example of an implementation where
> >> sizeof(short int) does not divide sizeof(int) or
> >> sizeof(int) does not divide sizeof(long int) or
> >> sizeof(long int) does not divide sizeof(long long int) ?
> >>
> >> Same question for the corresponding unsigned types.
> >
> > How about where sizeof int is not evenly divisible by sizeof char?
> > CDC Cyber UTexas C compiler
> >
> > 60 bits is not divisible by 8. They stored characters two words at a
> > time though, so you had 120 bits, which is divisible by 8.
>
> sizeof(int) is divisible by sizeof(char) in any conforming C
> implementation; sizeof(char) is 1 by definition.
>
> Implementing C on a system with 8-bit characters and 60-bit integers
> would be, um, interesting.

KCC a C compiler for PDP-10 had an option to use 7 bit char instead of the
standard conforming default of 9 bits char (PDP-10 is a 36 bits computer).
This probably to help interoperability as chars on the PDP-10 were usually
packed 5 by 36 bit word with an unused bit. I've never used this option so
can't answer any of the numerous question that can be raised.

Yours,

--
Jean-Marc

In article <> writes:
> "Dik T. Winter" <> writes:
>
> > We shifted to a CDC Cyber around 1976, or perhaps earlier. The first time
> > I even heard about the UTexas C compiler was about 10 years later. That was
> > when the computing centre asked us whether it should be available as a
> > standard compiler kit, I do not think it was much older. My answer to
> > the question was: *no*. The reason was that it was not suitable for
> > interactive work (the compiler required too much memory).
> > [...]
>
> Out of curiosity: how much memory was considered too much for a
> compiler to consume on that machine at the time?

The machine had 131,072 words of memory for over 100 simultaneous
interactive users. The limit for an interactive session was
28,672 words. If I remember well, the C compiler needed 40,960
words.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

In article <> writes:
> user923005 wrote:
....
> > 60 bits is not divisible by 8. They stored characters two words at a
> > time though, so you had 120 bits, which is divisible by 8.
>
> I suspect you are confusing CHAR_BIT with sizeof char.

I have mused a bit about it. I think now that the UTexas C compiler
used 12 bit chars (one of the possible variants on that system).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

In article <> Keith Thompson <kst-> writes:
> "Dik T. Winter" <> writes:
> > In article <. com>
> > "user923005" <> writes:
> [snip]
> > > How about where sizeof int is not evenly divisible by sizeof char?
> > > CDC Cyber UTexas C compiler
> [snip]
> > That is possible (but gives problems with floats that are also 60 bits).
> > But on those machines it is much more reasonable to have 48 bit ints
> > with the remaining 16 bits (possible) garbage. But integer arithmetic
> > on those machines had quite a few strange points. That is, I could
> > easily construct examples where:
> > (a + a) * 2 != a + a + a + a
> > in integer arithmetic, even when a < 2**48.
>
> I'm having trouble imagining that that's anything other than WRONG
> (assuming there's no overflow).

If the compiler tells you an int is 60 bits, there is no overflow, and
it is indeed wrong. If the copiler tells you an int is 48 bits, there
is overflow, and it is not wrong. So it is much more reasonable to tell
that ints are 48 bits. (The reason behind it is that the multiply
instruction used also serves as instruction to calculate the second half
of the product of two floating point numbers. When what is done depends
on the actual operands.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

"user923005" <> wrote:

> Dik T. Winter wrote:
> > In article <. com> "user923005" <>
> > > How about where sizeof int is not evenly divisible by sizeof char?
> > > CDC Cyber UTexas C compiler
> >
> > That would violate the standard. sizeof is expressed as an integral
> > unit, where sizeof char == 1. And that was already true in K&R.
>
> I wonder if it was written between 1969 (~ eariliest origins of C) and
> 1978 (K&R I published), in which case K&R I does not apply.

I have here PDFs of texts (from the look of it drafts of K&R I) by
Messrs Kernighan and Ritchie, apparently from 1974, which seem to claim
that in those days, a char was one byte large, and sizeof reported in
bytes. OTOH, the same documents also indicate that char used strict
ASCII, and only actually used 7 bits out of those 8-bit bytes. Draw your
own conclusion; I punt.

Richard

"christian.bau" <> ha scritto nel messaggio
news: ps.com...
> Spiros Bousbouras wrote:
> > Do you have an example of an implementation where
> > sizeof(short int) does not divide sizeof(int) or
> > sizeof(int) does not divide sizeof(long int) or
> > sizeof(long int) does not divide sizeof(long long int) ?
> >
> > Same question for the corresponding unsigned types.
>
> What about...
>
> An implementation where long has 40 value bits... (TI DSPs)


If you are thinking about "TI DSP C6X family":

WIDTH(int) = 32
WIDTH(long) = 40

but

sizeof (int) = 4
sizeof (long) = 8

In general "WIDTH(T1) does not divide WIDTH(T2)"

does not implies

"sizeof (T1) does not divide sizeof (T2)".


--
Giorgio Silvestri
DSP/Embedded/Real Time OS Software Engineer

Giorgio Silvestri wrote:
> "christian.bau" <> ha scritto nel messaggio
> news: ps.com...
> > Spiros Bousbouras wrote:
> > > Do you have an example of an implementation where
> > > sizeof(short int) does not divide sizeof(int) or
> > > sizeof(int) does not divide sizeof(long int) or
> > > sizeof(long int) does not divide sizeof(long long int) ?
> > >
> > > Same question for the corresponding unsigned types.
> >
> > What about...
> >
> > An implementation where long has 40 value bits... (TI DSPs)
>
>
> If you are thinking about "TI DSP C6X family":
>
> WIDTH(int) = 32
> WIDTH(long) = 40
>
> but
>
> sizeof (int) = 4
> sizeof (long) = 8
>
> In general "WIDTH(T1) does not divide WIDTH(T2)"
>
> does not implies
>
> "sizeof (T1) does not divide sizeof (T2)".

By width do you mean the number of value bits ?