A byte can be greater than 8 bits?

[Walter Roberson]

I was asking for individuals input. Anyone can google.

Some people need examples. I am one such. The examples I am looking to
gather in a single place are to avoid having to rely on certain posters
assertions.

I have *individually* indicated a few times in the past that
I have personally worked on Honeywell L6 series machines which
used 9 bit characters. But since you do not appear to have chosen
to have listened to that, it would appear that I am one of
the "certain posters" whose assertions you do not trust.

Perhaps you will be more trusting of this header file, marked
copyright Motorola:

http://leo.sprossenwanne.at/dsp/Entwicklungsprogramme/Entpack/CC56/DSP/INCLUDE/LIMITS.H

/* the 561c supports 16 bit chars and ints, and 32 bit longs. */
/* the 56k supports 24 bit chars and ints, and 48 bit longs. */
/* the 96k supports 32 bit chars, ints, and longs. */

Or this data sheet from Texas Instruments:
http://www.datasheetarchive.com/preview/3430205.html
(Note the lack of 8 bit I/O -- everything is in 16 bit "words")

 

[CBFalconer]

.... snip ...

Personally, I would prefer if Standard C mandated 2s-complement
and defined the behaviour of shifting signed integer types left
and right. Maybe we should define a new language, Real-C where
these awkward historical detail would be removed...

Horrors. Then Real-C might even become popular, and all sorts of
code written in it by eager neophytes, which code can no longer be
made to run on older or newer machines, which in turn take
advantage of one or more of the known (or presently unknown)
advantages of sign-magnitude or 1's complement.

 

[Kenneth Brody]

A small quibble: Putting C identifiers or keywords in all-caps for
emphasis is not a good idea. void is a keyword; VOID is an identifier
and could very plausibly be a macro name (for example, I've seen code
that conditionally uses ``#define VOID int'' for pre-ANSI
compatibility).
BTDTGTHF.

This is, as the phrase "small quibble" implies, not a
big deal, and I wouldn't have bothered to mention if it I weren't also
making another point.

Attempting to convert a function pointer to void* invoked undefined
behavior. (I had thought it was a constraint violation, but a quick
check of the standard doesn't support that.) A compiler isn't even
required to compile code that attempts such a conversion, regardless
of whether it *could* meaningfully do so. I would be unsurprised to
see a C compiler that rejects a program that attempts such a
conversion.

The compiler on this system, with warnings turned up, gives a warning
about "nonstandard extension, function/data pointer conversion in
expression". But, it does compile.

As for a specific example, I believe IBM AS/400 has been presented
here as such a system. My vague recollection is that function
pointers are considerably larger than void*. I've never used an
AS/400 system, so I can't confirm that.

Well, on a related note, the AS/400 C compiler manual does say:

When you convert a valid function (procedure) pointer, system
pointer, invocation pointer, label pointer, or suspend pointer
to a signed or unsigned integer type, the result is always zero.

http://publib.boulder.ibm.com/infoc...om.ibm.etools.iseries.pgmgd.doc/cpprog440.htm

I don't see anything about code-vs-data pointers.

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Flash Gordon]

Kenneth Brody wrote, On 01/10/07 21:26:

Because is just looks "wrong".

To me, it looks like "take negative one as an unsigned value", even
though the real meaning is "negate the unsigned int value 1, and give
the result as an unsigned int".

In other words, as I understand it (now that I've looked into it a
little), "-1u" is really two tokens -- "-" and "1u".

Either interpretation will give you the correct result in this case. -1
converted to unsigned int is guaranteed to be UINT_MAX. An unsigned int
with a value of 1 that is negated is also guaranteed to give you
UINT_MAX. However, in the case of C, there is not really any such thing
as a negative constant, there are only positive constants which are the
operand of a unary minus. This is why you often see odd looking
definitions of INT_MIN if you look in limits.h

There is no promotion involved, the u is part of the token 1u.

the '-' negates this. The result (mathematical

Again, no promotion involved, but the basic idea is correct.

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

Attempting to convert a function pointer to void* invoked undefined
behavior. (I had thought it was a constraint violation, but a quick
check of the standard doesn't support that.) A compiler isn't even
required to compile code that attempts such a conversion, regardless of
whether it *could* meaningfully do so. I would be unsurprised to see a
C compiler that rejects a program that attempts such a conversion.

If the behaviour is undefined, the compiler must accept the conversion,
unless it can prove the conversion will be performed in every possible
execution path of the program.

You're right that the behaviour is undefined. It should be a constraint
violation. Compilers in practise already treat it as such. This is
similar to conversions between pointers and floating point types.

 

[CBFalconer]

.... snip ...

If you're not getting some of the specific examples you're asking
for, it may be partly because some of the people who know about
such example have killfiled you. Behavior has consequences.

I'm in that group (plonkers). Know about is another question, and
varies. I have unplonked all from the topicality thread. So far I
have not found any that deserve permanent unplonking.

 

[Ben Bacarisse]

Kenneth Brody wrote, On 01/10/07 21:26:

Either interpretation will give you the correct result in this
case. -1
converted to unsigned int is guaranteed to be UINT_MAX. An unsigned
int with a value of 1 that is negated is also guaranteed to give you
UINT_MAX. However, in the case of C, there is not really any such
thing as a negative constant, there are only positive constants which
are the operand of a unary minus. This is why you often see odd
looking definitions of INT_MIN if you look in limits.h


There is no promotion involved, the u is part of the token 1u.

I did not say there was. Arithmetic operations are defined to be
applied to the promoted operand and, in case anyone quibbled, I was
stating that what the promoted type is. Obviously this requires no
actual action.

Again, no promotion involved, but the basic idea is correct.

and again I did not say there was. The definition of '-' says that
the "result has the promoted type" -- I was using that wording to
prevent any quibbles!

 

[CBFalconer]

.... snip ...

and again I did not say there was. The definition of '-' says that
the "result has the promoted type" -- I was using that wording to
prevent any quibbles!

On c.l.c? You must be dreaming.

 

[Ian Collins]

I'm in that group (plonkers).

Now you wouldn't want to make that admission in the British English
speaking world

 

[Sjouke Burry]

Now you wouldn't want to make that admission in the British English
speaking world

Tssk... A dirty mind is a joy forever
But do you HAVE to let us know that??

 

[Richard Heathfield]

Keith Thompson said:

If you're not getting some of the specific examples you're asking for,
it may be partly because some of the people who know about such
example have killfiled you. Behavior has consequences.

Indeed it does. So does a marked improvement in behaviour, though. If it
ever happens, presumably it will show up in replies from those who haven't
killfiled him, and that may well lead to some modding up. In the meantime,
his constant unpleasantness has damaged his chances of getting good
answers to the questions he asks here. I doubt very much whether my
killfile is the only one he's in.

 

[Jack Klein]

I partly agree and partly disagree here. I agree because it shows to new
people that strictly following the standard /is/ important because these
common assumptions aren't necessarily true. But I disagree because it
may encourage the view that if a system cannot be found which differs
from the norm, then it doesn't matter that we're making assumptions.


DSPs are a common example here.

Specifically, the TMS32C28xxx DSP family from Texas Instruments,
extremely popular in motion control and power supply generation.

CHAR_BIT is 16, sizeof(char)==sizeof(short)==sizeof(int) = 1.
sizeof(long) = 2. sizeof(long long) = 4. sizeof(float) = 2.

Not a "theoretical possibility", but a part I do a lot of work with,
including writing code for today.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Jack Klein]

K. Thomson said it was in a very old Cray implementation. Probably
the newer ones do not use that since ages.

So you address the issue of Keith Thompson's posts, but ignore mine?
There is nothing obsolete or old about the TMS320C28xxx DSP family
that I am using today on multiple circuit boards. The production
version of the original parts began shipping less than 3 years ago.

Since then they have added literally dozens of models in the family,
the newest ones introduced in June and just starting to ship now.

Just to convince you, here is a copy and past from a small part of the
manual for the C and C++ compiler:

<--begin quotation-->
Type Size Representation Minimum Maximum
char, signed char 16 bits ASCII 32768 32767
unsigned char 16 bits ASCII 0 65535
short 16 bits 2s complement 32768 32767
unsigned short 16 bits binary 0 65535
int, signed int 16 bits 2s complement 32768 32767
unsigned int 16 bits binary 0 65535
long, signed long 32 bits 2s complement 2147483648 2147483647
unsigned long 32 bits binary 0 4294967295
<--end quotation-->

That's from a version of the compiler from several years ago. The
newer version adds 64-bit signed and unsigned long long, 64 bits, four
bytes.

I wrote (and linted and compiled) code for this implementation TODAY.

The best estimates I have seen recently are that about 2% of the CPU
chips made in the world today go into desktop, laptop, server, or
workstation products as the main processor, 32- or 64- bit chips
executing in a hosted environment of Windows, MacOS, various other
UNIX/Linux flavors, OS/2, QNX, VxWorks, and so on.

You are not familiar with more than a small percentage of these
processor/OS combinations, and next to nothing at all about the
operating environments and programming of the remaining 98% of the
CPUs made in the world.

While C is becoming much less widely used on the hosted platforms
listed above, it is the main tool for those other 98%.

You seem to think that your experience, however great, on 32- and
64-bit hosted environments makes you a profound expert on all C
platforms and implementations everywhere and anywhere. You could not
be more mistaken.

Just because your compiler and your customers have no interest in C
implementations where CHAR_BIT is 16, or 24, or 32, your arrogance
leads you to pronounce that such systems do not exist, or are not
important.

You are very, very wrong and in your arrogance you parade your
ignorance.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Keith Thompson]

Keith Thompson wrote: [...]

A small quibble: Putting C identifiers or keywords in all-caps for
emphasis is not a good idea. void is a keyword; VOID is an identifier
and could very plausibly be a macro name (for example, I've seen code
that conditionally uses ``#define VOID int'' for pre-ANSI
compatibility).

BTDTGTHF.

?

 

[Mike Smith]

Are you joking? I asked for some examples of systems. Not vague "maybe
these". So, no, to be honest your "I think there are some DSPs" is not a
good enough example :-; Sorry. Your example is no more helpful than the
"On some systems a byte is more than 8 bits" type statements. Not
helpful to someone new who might like to see a concrete example. Maybe I
was not clear enough in which case I apologise. But it seems you don't
have any experience of any such platforms - so be it.

As for putting some "effort" in - I am. I am asking *here* where there
are a plethora of people who know a lot about such systems. I am hoping
they will give some examples of where a byte is more than 8 bits or
CHAR_BITS is more than 8. And it is a benevolent quest. I want to see
these systems and look at their specs too. It would be really good to
reference them whenever telling people their code is not standards
compliant.


But to do that you need to know the standard backwards. Whereas real
examples give real warnings.

From a "real" system that is running today:

#include<stdio.h>
#include<types.h>
int main (void)
{
printf("size of a byte is %d\n", CHAR_BIT);
return 0;
}
-c * +go
Gcos8 C rcl3.3
size of a byte is 9

 

[Richard]

From a "real" system that is running today:

#include<stdio.h>
#include<types.h>
int main (void)
{
printf("size of a byte is %d\n", CHAR_BIT);
return 0;
}
-c * +go
Gcos8 C rcl3.3
size of a byte is 9

What is

-c * +go
Gcos8 C rcl3.3

? And what real system? Thanks for the example.

 

[Mike Smith]

What is


? And what real system? Thanks for the example.

"-" is the command line prompt, "c * +go" invokes the compiler
and then runs the resulting output.

The hardware is Bull DPS9000 (a descendant of the Honeywell L66
range that was itself a descendant of the GE-600). The GCOS8 operating
system is still in active use today.

 

[jacob navia]

"-" is the command line prompt, "c * +go" invokes the compiler
and then runs the resulting output.

The hardware is Bull DPS9000 (a descendant of the Honeywell L66
range that was itself a descendant of the GE-600). The GCOS8 operating
system is still in active use today.

I used a gcos8 in 1985. This is an historical machine without
any real usage today. Of course, there are maybe 10-20
installations all over the world, but... I would not care
really.

 

[Martin Wells]

jacob:

Of course, there are maybe 10-20
installations all over the world, but... I would not care
really.

Given you don't care about porting from one version of windows to the
next, it's hardly suprising you don't care about this.

Martin

 

[Richard Tobin]

Given you don't care about porting from one version of windows to the
next, it's hardly suprising you don't care about this.

For the vast majority of software, not being able to run on a handful of
mainframes really doesn't matter at all.

-- Richard