dependency of sizeof operator

[vandana]

Output of sizeof(int) varies.But on what it depends.Can anybody please
help me to find out if it is compiler dependent or operating system
dependent?

 

[Ben Pfaff]

Output of sizeof(int) varies.But on what it depends.Can anybody please
help me to find out if it is compiler dependent or operating system
dependent?

It depends on the C implementation; roughly speaking, on the
compiler. But the C implementation is often strongly influenced
by the operating system and the CPU architecture.

 

[daya]

It depends on the machine you are using and the compiler also. e.g if
you use turboC/C++ to get sizeof (int) you get 2 but on the same
machine if you use gcc or MS Visual studio sizeof(int)=4 .

 

[Malcolm McLean]

Output of sizeof(int) varies.But on what it depends.Can anybody please
help me to find out if it is compiler dependent or operating system
dependent?

int should be the same size as a register. However some wicked people have
implemented 32 bit ints on 64-bit machines. So it is up to the compiler
writer.

 

[swengineer001]

int should be the same size as a register. However some wicked people have
implemented 32 bit ints on 64-bit machines. So it is up to the compiler
writer.

There is no requirement for an int to match the register size of the
machine it is running on so why would you say it should be that size?

 

[Malcolm McLean]

There is no requirement for an int to match the register size of the
machine it is running on so why would you say it should be that size?

It was always the intention that int should be the natural word size, or in
other words a register. That is why it is not a fixed width, and why
functions used to implicitly return ints.
Since the standard makes no guarantees about execution time it wouldn't be
sensible to make this a requirement. We are not yet comp.lang.ANSIc and
"should" is not synonymous with "ANSI says".

 

[Richard Tobin]

It was always the intention that int should be the natural word size,

Modern processors typically don't have only one natural word size.
Just because a processor can manipulate 64-bit words as a unit doesn't
mean that 32-bit words are no longer the natural choice for many
purposes.

-- Richard

 

[Flash Gordon]

Malcolm McLean wrote, On 23/03/07 20:10:

int should be the same size as a register. However some wicked people
have implemented 32 bit ints on 64-bit machines. So it is up to the
compiler writer.

What if the inputs to the ALU (and multiplier) are 16 bits but the
actual accumulator and product register are all 32 bits? Before you ask
who would do something that screwy, it is Texas Instruments who are not
exactly small in the DSP market.

 

[Jack Klein]

int should be the same size as a register. However some wicked people have
implemented 32 bit ints on 64-bit machines. So it is up to the compiler
writer.

No, it should not necessarily be the same size as a register. The C
Standard _specifically_ state:

A ‘‘plain’’ int object has the natural size suggested by the
architecture of the execution environment (large enough to contain any
value in the range INT_MIN to INT_MAX as defined in the header
<limits.h>).

There are an enormous number of 8-bit controllers and processors
produced running C code each year, at least an order of magnitude more
of them then there are of the desktop CPUs that you seem to think
constitute the whole world. Some of them could not support a C
implementation if int had to be the same size as a register, because
they have no registers wider than 8 bits.

--
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

 

[Malcolm McLean]

There are an enormous number of 8-bit controllers and processors
produced running C code each year, at least an order of magnitude more
of them then there are of the desktop CPUs that you seem to think
constitute the whole world. Some of them could not support a C
implementation if int had to be the same size as a register, because
they have no registers wider than 8 bits.

Nowadays I program mainly either desktops or Beowulf clusters, however I
used to be a games programmer in times past.
Actually the C compiler on one small embedded system I never actually used,
though I prepared a bid for a project with it, had ints of 8 bits. I suppose
now you'll say the failure to get the contract was a reflection of my
incompetence, which I suppose it was.

 

[Keith Thompson]

Nowadays I program mainly either desktops or Beowulf clusters, however
I used to be a games programmer in times past.
Actually the C compiler on one small embedded system I never actually
used, though I prepared a bid for a project with it, had ints of 8
bits.

In a conforming C implementation, int must be at least 16 bits (more
precisely, it must be able to represent all value in the range -32767
... +32767). The implementation you describe may well have been quite
useful, but it wasn't a conforming C implementation. Or it may have
been produced before the C89 standard came out, in which case there
was no standard to conform to.

As long as it didn't *claim* to conform to the C standard, I have no
objection to such a thing, though I'd prefer that it not refer to
itself as "C" without qualification.

 

[Malcolm McLean]

In a conforming C implementation, int must be at least 16 bits (more
precisely, it must be able to represent all value in the range -32767
.. +32767). The implementation you describe may well have been quite
useful, but it wasn't a conforming C implementation. Or it may have
been produced before the C89 standard came out, in which case there
was no standard to conform to.

As long as it didn't *claim* to conform to the C standard, I have no
objection to such a thing, though I'd prefer that it not refer to
itself as "C" without qualification.

It was an under-powered little thing with something like 4K of RAM, all on
the same chip, and it was proposed to use it to run a parking ticket vending
machine. The customer also asked of an "object-oriented design". I said I
couldn't do OOD in 4K, which made their technical guy look like an idiot,
and I strongly suspect that that was why we lost the contract. I'm too good
at antagonising people.
It stored all its variables in fixed locations and so didn't support
recursion. However it had a full math library with 3-byte doubles. longs
were 16 bits. It didn't have any IO of course, you had to write that
yourself, on hardware that was being developed. That might have been another
reason we lost the contract. I hadn't had any experience of developing
software for buggy hardware, so I told my boss that I was sceptical about
the alleged time estimations the customer had prepared.

 

[Peter Nilsson]

int should be the same size as a register.

[Jack's talked about 8-bit cpus, but...]

What's the register size for an interpreted implementation
of C? On x86 machines, should int be 16-bit to match the ax
register, or 32-bit to match the eax register?

 

[Malcolm McLean]

int should be the same size as a register.

[Jack's talked about 8-bit cpus, but...]

What's the register size for an interpreted implementation
of C? On x86 machines, should int be 16-bit to match the ax
register, or 32-bit to match the eax register?

Big enough to index an array. Which means 16 bits on the small memory models
and 32 bits on the large ones. However you could justifiably say that it is
more important to be consistent across models than to offer ints that work
as expected. Conventions and standards can't possibly be expected to cover
every weird architecture.

 

[Flash Gordon]

Malcolm McLean wrote, On 26/03/07 20:43:

Output of sizeof(int) varies.But on what it depends.Can
anybody please help me to find out if it is compiler
dependent or operating system dependent?

int should be the same size as a register.

[Jack's talked about 8-bit cpus, but...]

What's the register size for an interpreted implementation
of C? On x86 machines, should int be 16-bit to match the ax
register, or 32-bit to match the eax register?

Big enough to index an array. Which means 16 bits on the small memory
models and 32 bits on the large ones.

So given a processor with 16 bit arithmetic registers and a memory space
larger than 16 bits you want to slow down arithmetic with int or limit
the size of arrays.

> However you could justifiably say
that it is more important to be consistent across models than to offer
ints that work as expected. Conventions and standards can't possibly be
expected to cover every weird architecture.

The standard is expected to cover every wird architecture, that is part
of the point of it.

 

[Malcolm McLean]

Malcolm McLean wrote


So given a processor with 16 bit arithmetic registers and a memory space
larger than 16 bits you want to slow down arithmetic with int or limit the
size of arrays.

You've got to ask what sort of person would produce a machine with a data
register size narrower than the address bus. The obvious answer is someone
who thinks that a big memory is more important than speed in accessing it.
So it is unlikely to matter that we are slowing down integer arithemetic.

Addmittedly the convention, though not the standard, is breaking down in
such a case. Most computers spend most of their time computing array offsets
and fetching and writing data to and from them, certainly as far as integer
operations are concerned. However that is not true of every program, of
course, and so a very integer maths-intensive programmer would complain,
with justice, that int was not the fastest type. You've got to balance this
against the inconvenience of not being able to index an array with an int.

 

[Flash Gordon]

Malcolm McLean wrote, On 27/03/07 22:11:

You've got to ask what sort of person would produce a machine with a
data register size narrower than the address bus. The obvious answer is
someone who thinks that a big memory is more important than speed in
accessing it. So it is unlikely to matter that we are slowing down
integer arithemetic.

Lets start with the 80386SX which had a 16 bit data bus and a 24 bit
address buss, so fetching anything larger would require more than one
fetch. Run it with the large memory model so that you can have large
objects! Just the first off the top of my head ;-)
http://www.intel.com/design/intarch/intel386/index.htm

Addmittedly the convention, though not the standard, is breaking down in
such a case.

Cases which keep coming and going.

> Most computers spend most of their time computing array
offsets and fetching and writing data to and from them, certainly as far
as integer operations are concerned.

They may with your applications but I know a number of server and client
applications which only spend a small fraction of their time doing array
index operations. In fact, I can only think of one part of one
application where that was true.

> However that is not true of every
program, of course, and so a very integer maths-intensive programmer
would complain, with justice, that int was not the fastest type. You've
got to balance this against the inconvenience of not being able to index
an array with an int.

Do you really have any information at all to back up your claims? Since
I really do find that the majority of applications I have dealt with
over the years do more integer arithmetic because they wanted to do
integer arithmetic than because they were calculating array offsets.
Also, a number of processors have alternative ways of doing indexing
that do not involve normal arithmetic registers at all, so your argument
even if true would be irrelevant for them.

 

[Coos Haak]

Op Tue, 27 Mar 2007 23:33:08 +0100 schreef Flash Gordon:

Lets start with the 80386SX which had a 16 bit data bus and a 24 bit
address buss, so fetching anything larger would require more than one
fetch. Run it with the large memory model so that you can have large
objects! Just the first off the top of my head ;-)
http://www.intel.com/design/intarch/intel386/index.htm

The 68000 had also a 16 bit external data bus, but internally both were 32
bits. I think they were 32 bit CPUs although the '486 and 68020 were true
ones, as they had a 32 bit external data bus.
Would you call the 68008 and 8088 8 bitters?

 

[Malcolm McLean]

Malcolm McLean wrote, On 27/03/07 22:11:


They may with your applications but I know a number of server and client
applications which only spend a small fraction of their time doing array
index operations. In fact, I can only think of one part of one application
where that was true.


Do you really have any information at all to back up your claims? Since I
really do find that the majority of applications I have dealt with over
the years do more integer arithmetic because they wanted to do integer
arithmetic than because they were calculating array offsets. Also, a
number of processors have alternative ways of doing indexing ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that do not involve normal arithmetic registers at all, so your argument ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
even if true would be irrelevant for them. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--
Flash Gordon
In assembler I once ended up using the addressing units on one processor
to do integer arithmetic (not addressing related) so I could get a higher
throughput of integer operations.

You're making an elementary mistake. If an integer is used to index an
array, all operations used to calculate that index are indexing operations,
not just the ones within the square brackets.
You'll find that most genuinely numerical data is real and therefore stored
as floating points. I don't say absolutely all - an exception would be a
program that does very intensive work with 24-bit rgba values, or programs
which operate on data which is inherently real but stored in fixed-point
format for speed. Generally however integer are for counting things, and
those things tend to be items stored in the computer.

 

[Flash Gordon]

Malcolm McLean wrote, On 28/03/07 20:12:

You're making an elementary mistake. If an integer is used to index an
array, all operations used to calculate that index are indexing
operations, not just the ones within the square brackets.

No, I'm not. You are making the elementary mistake of assuming you know
more about what I have worked on than I do. You are also making the
mistake of assuming that you know more about the processors I have
worked on than you do. On the processors I was referring to I was doing
most of the calculations that had ANYTHING to do with indexing in the
addressing units (normally adding 1 each time, but sometimes more
convoluted things) and had enough spare power left in the addressing
units that when doing assembler coding I was doing arithmetic in them
that was NOT related to indexing in any way, shape, or form. Unless in
the following:
arr = x*x+y;
You would consider the "x*x+y" to be to do with indexing, in which case
you are not using a sensible definition.

You'll find that most genuinely numerical data is real and therefore
stored as floating points.

All the numerical data on a lot of aircraft relating to relating to
roll, pitch and altitude is passed around as scaled integers, as I know
having worked on a number of them. All the video data in a lot of
systems is passed around and processed as integers, I know having worked
on them.

> I don't say absolutely all - an exception
would be a program that does very intensive work with 24-bit rgba
values,

There is a heck of a lot of image processing software around in daily
use, probably rather more than you would expect since I doubt you would
immediately think of some of the stuff I've worked on.

> or programs which operate on data which is inherently real but
stored in fixed-point format for speed.

Such as is the case in a lot of aircraft systems, or at least all of the
several systems I have worked on.

> Generally however integer are
for counting things, and those things tend to be items stored in the
computer.

How about money? You generally need a finite number of decimal places.
The same applies to most measures in billing systems, invoicing systems,
cost control systems etc. (I work on such systems these days, so I know
how a subset of them work).

Now, do you have any evidence that what you are claiming is actually
true or is it just based on your limited experience?

Note that I'm not claiming that most integer arithmetic is not to do
with indexing, I only have a bit over 20 years experience so there is a
vast amount I have not seen, I am only asking if you have any REAL
justification for believing what you claim, such as a study that
actually does cover a large section of the SW industry.