If you could take a minute to compile and run the following program on
whatever 64-bit machines you have available, and mail me the results along
with an English description of your environment I would appreciate it.
I will post a summary if there is interest.
Thanks,
Mark
#include <stdio.h>
int
main()
{
system("uname -a");
/* conventional C types */
printf("sizeof(char) = %ld\n", sizeof(char));
printf("sizeof(short) = %ld\n", sizeof(short));
printf("sizeof(int) = %ld\n", sizeof(int));
printf("sizeof(long) = %ld\n", sizeof(long));
printf("sizeof(char *) = %ld\n", sizeof(char *));
/* you will likely have to delete one or more of these to compile */
printf("sizeof(_int32) = %ld\n", sizeof(_int32));
printf("sizeof(_int64) = %ld\n", sizeof(_int64));
printf("sizeof(long long) = %ld\n", sizeof(long long));
printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));
/* if your 64-bit environment has some other
oddball-yet-vital 64-bit data types, please add them */
exit(0);
} /* main */
On an SGI machine, it gives;
"t.c", line 17: error(1020): identifier "_int32" is undefined
printf("sizeof(_int32) = %ld\n", sizeof(_int32));
^
"t.c", line 18: error(1020): identifier "_int64" is undefined
printf("sizeof(_int64) = %ld\n", sizeof(_int64));
^
"t.c", line 20: error(1020): identifier "__longlong" is undefined
printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));
--
Regards, | I don't believe in the carrot anymore;
Ian Ameline, | I think it's just another stick that's
Senior Software Engineer, | been painted orange.
Alias/Wavefront |
> In article <mbhExL...@netcom.com>, Mark Hanson <m...@netcom.com> wrote:
> >I'm taking a survey to find out how different C compilers handle long
> >data types in 64-bit environments.
> >
> >If you could take a minute to compile and run the following program on
> >whatever 64-bit machines you have available, and mail me the results along
> >with an English description of your environment I would appreciate it.
>
> [ snip ]
>
> > printf("sizeof(char) = %ld\n", sizeof(char));
>
> * Cough *
>
> I ran it on my DeathStation 9000 and demons flew out of my nose.
>
> Don't you know that %ld requires an argument of type unsigned long, and that
signed long
> sizeof yields a value of type size_t, which is not necessarily compatible with
> unsigned long?
<Jack>
But it's good to have you back again, Kaz. :)
</Jack>
Kaz has not been getting enough coffee. He meant, of course, that
%ld is the type specifier for a signed long.
The way to use printf with size_t is (until C9x)
printf("%lu", (unsigned long) sizeof(int));
I'd say that this is guaranteed to NOT compile on any sysyrem you can think
of. Mayb yo should've just asked people to send what their documentation says
about 64 bit ints (if anything)
--
Tristan Styles
Failure is not an option
It is Standard Operating Procedure
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
>> #include <stdio.h>
You need #include <stdlib.h> for system() and exit().
>> int
>> main()
>> {
>> system("uname -a");
Many platforms wont understand "uname -a".
>> /* conventional C types */
>> printf("sizeof(char) = %ld\n", sizeof(char));
%ld is for converting arguments of type long. sizeof produces a result of
type size_t which can be any unsigned integer type. SO one type you know for
sure that it isn't is long. Since the actual type is unknown you
need a cast. Assuming that the result can be represented in an int (which
is a reasonable assumption here) you can write:
printf("sizeof(char) = %d\n", (int)sizeof(char));
and so on.
>> printf("sizeof(short) = %ld\n", sizeof(short));
>> printf("sizeof(int) = %ld\n", sizeof(int));
>> printf("sizeof(long) = %ld\n", sizeof(long));
>> printf("sizeof(char *) = %ld\n", sizeof(char *));
>>
>> /* you will likely have to delete one or more of these to compile */
>> printf("sizeof(_int32) = %ld\n", sizeof(_int32));
>> printf("sizeof(_int64) = %ld\n", sizeof(_int64));
>> printf("sizeof(long long) = %ld\n", sizeof(long long));
>> printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));
>>
>> /* if your 64-bit environment has some other
>> oddball-yet-vital 64-bit data types, please add them */
>>
>> exit(0);
>> } /* main */
>>
>
>I'd say that this is guaranteed to NOT compile on any sysyrem you can think
>of. Mayb yo should've just asked people to send what their documentation says
>about 64 bit ints (if anything)
Ignoring the <stdlib.h> issue the only problem is the stuff after the
/* you will likely have to delete one or more of these to compile */
comment. But clearly that comment acknowledges what you are saying and
even suggests a remedy.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
}[ snip ]
}> printf("sizeof(char) = %ld\n", sizeof(char));
}* Cough *
}I ran it on my DeathStation 9000 and demons flew out of my nose.
}Don't you know that %ld requires an argument of type unsigned long, and that
}sizeof yields a value of type size_t, which is not necessarily compatible with
}unsigned long?
Well, I'm sure we can look forward to:
printf("sizeof(char) = %<size_t>\n", sizeof(char));
RSN.
John
--
John Hascall, Software Engr. | "One World, One Web, One Program" - Microsoft Ad
ISU Computation Center | "Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler
mailto:jo...@iastate.edu |
http://www.cc.iastate.edu/staff/systems/john/welcome.html <-- the usual crud
[ regarding printing the value of a size_t object ]
|> Well, I'm sure we can look forward to:
|>
|> printf("sizeof(char) = %<size_t>\n", sizeof(char));
|>
|> RSN.
Ahh, wishful thinking. :-) A bit closer to the mark might be
printf("sizeof(char) = %" PRIuMAX "\n", (uintmax_t) sizeof(char));
But fortunately, this can be shortened:
printf("sizeof(char) = 1\n");
Regards,
--
Chris Engebretson - Raytheon STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6940
http://edcwww.cr.usgs.gov/ mailto:enge...@sg1.cr.usgs.gov
Opinions are not those of Raytheon Systems Company or the USGS.
1 char, obviously.
--
John Kugelman. kuge...@mnsinc.com
I believe we can change anything.
I believe in my dream.
- Joe Satriani
>But fortunately, this can be shortened:
>
> printf("sizeof(char) = 1\n");
1 what though?
--
Bob Cousins, Software Engineer.
Home page at http://www.lintilla.demon.co.uk/
|> In comp.arch, Chris Engebretson wrote:
|>
|> >But fortunately, this can be shortened:
|> >
|> > printf("sizeof(char) = 1\n");
|>
|> 1 what though?
sizeof(char) is 1 by definition.
>In comp.arch, Chris Engebretson wrote:
>
>>But fortunately, this can be shortened:
>>
>> printf("sizeof(char) = 1\n");
>
>1 what though?
1 char (clearly), 1 byte (equivalently in C), 1 lump of CHAR_BIT bits (where
CHAR_BIT is defined in <limits.h> and can be 8 or more).
>
>Bob Cousins wrote in message <35de92c9...@news.demon.co.uk>...
>|In comp.arch, Chris Engebretson wrote:
>|
>|>But fortunately, this can be shortened:
>|>
>|> printf("sizeof(char) = 1\n");
>|
>|1 what though?
>|
>=======
>1 char, of course, you silly. The description of sizeof in the
>standard says "bytes", but a byte is defined in C to mean only the
>space a char takes. And the definition of sizeof says explicitly that
>"When applied to an operand that has type char, unsigned char, or signed
>char (or a qualified version thereof) the result is 1."
>[Note the misplaced ','].
I assumed the original poster would want to find the size of long types in terms
of bits. I guess I missed the point of the survey.
Yep -- straight out of ANSI X3.159-1989 Section 3.3.3.4, lines 32 and 33.
int main() requires a return value.
>
>Mark Hanson wrote in message ...
>>#include <stdio.h>
>>
>>int
>>main()
>>{
>> system("uname -a");
>>
>> /* conventional C types */
>> printf("sizeof(char) = %ld\n", sizeof(char));
>> printf("sizeof(short) = %ld\n", sizeof(short));
>> printf("sizeof(int) = %ld\n", sizeof(int));
>> printf("sizeof(long) = %ld\n", sizeof(long));
>> printf("sizeof(char *) = %ld\n", sizeof(char *));
>>
>> /* you will likely have to delete one or more of these to compile */
>> printf("sizeof(_int32) = %ld\n", sizeof(_int32));
>> printf("sizeof(_int64) = %ld\n", sizeof(_int64));
>> printf("sizeof(long long) = %ld\n", sizeof(long long));
>> printf("sizeof(__longlong) = %ld\n", sizeof(__longlong));
>>
>> /* if your 64-bit environment has some other
>> oddball-yet-vital 64-bit data types, please add them */
>>
>> exit(0);
>>} /* main */
>
>int main() requires a return value.
No it doesn't. If control passes to the end of the main function, it
returns and undefined termination status to the operating system but,
1. that is permitted by the standard.
2. that doesn't apply here since control never passes to the
end of main.
--
Michael M Rubenstein
1 char. The sizeof operator returns size in chars.
CHAR_BIT is the number of bits in a char, if that's what you mean.
Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for DSC. <- They make me say that.
}> 1 char, of course, you silly. The description of sizeof in the
}> standard says "bytes", but a byte is defined in C to mean only the
}> space a char takes. And the definition of sizeof says explicitly that
}> "When applied to an operand that has type char, unsigned char, or signed
}> char (or a qualified version thereof) the result is 1."
}Yep -- straight out of ANSI X3.159-1989 Section 3.3.3.4, lines 32 and 33.
By focusing in on 'sizeof(char) == 1' it seems to me
that everyone has avoided the real question -- which is:
how do you portably know which printf format specifier
goes with
foo_t
for whatever 'foo' (e.g., size_t).
You have to cast to a compatible, printable type, such as unsigned long
for size_t.
BTW, you should lose the indentation. It's... strange.
Call for Participation
Compiler and Architecture Support for
Embedded Computing Systems (CASES98)
An International Workshop
November 4-5, 1998
Washington D.C.
Over the past decade, substantial research has gone into the design of
microprocessors embodying parallelism at the instruction-level, as well as
aggressive compiler optimization and analysis techniques for harnessing this
opportunity. Much of this effort has since been validated through the
proliferation of "product quality" general purpose computers based on these
technologies. Growing demand for high performance in embedded computing
systems is creating new opportunities to leverage instruction-level
parallelism (ILP) or Explicitly Parallel Instruction Computing (EPIC)
technology including application-specific domains. Embedded computers are
increasingly present in day to day settings. Examples where ILP may address
the need for high performance and application specific embedded computing
include set-top boxes, hand-held games, mobile and web appliances, and
advanced automotive systems.
However, several novel challenges have to be overcome in order to
harness the opportunities offered by EPIC style architectures in the
context of embedded systems. Constraints on the code size, weight and power
consumption place stringent requirements on the processors and the software
they execute. Also constraints rooted in real-time requirements are often a
significant consideration in many embedded systems. Furthermore, the cost is
a severe constraint on embedded processors. In this regard, the needs of
embedded computing differ from those of more traditional general purpose systems.
----------------------------------------------------------------------------
INVITED SPEAKERS
Josh Fisher, Hewlett-Packard Labs,
Other Speaker(s) TBA
----------------------------------------------------------------------------
About this Workshop
This workshop is an informal forum for researchers to discuss their ideas centered
on emerging technology themes with emphasis on the synergy between processors
that embody instruction level parallelism, and high performance embedded
systems. Thus, enabling high-performance embedded technologies using ILP will
be a significant, albeit not an exclusive goal. Technical as well as position
papers espousing significant novel ideas and technical results are solicited.
Suggested topics include (but are not limited to) the following:
* Application specific design and synthesis.
* Research challenges and solutions in microarchitecture design for
embedded systems based ILP.
* Research directions in embedded system software tools, with emphasis
on light-weight languages for temporal specification. Optimizing
compilers for ILP exploitation in the presence of temporal constraints.
* Harnessing the interaction between the hardware and software layers,
spurred by innovations in reconfigurable or adaptive computing systems.
* Characterizing the need of research infrastructure development for
embedded systems based on ILP and adaptive technologies.
* Synergy between extant parallel computing technologies, such as
notations for expressing concurrency, and instruction level parallel
processing, with emphasis on concerns of embedded computing.
* Compiler Controlled Memory Hierarchy Management and Smart Caches.
Presentation of ongoing work is encouraged. No formal proceedings are
planned; therefore the results presented in the workshop can be published in
archival journals. However, there is a plan to invite high quality papers
presented at the workshop, as the candidates for a special monograph based
on the workshop's theme.
In addition to the presentations, the workshop will have
* A panel constituted of experts from industry, government and academic
research organizations to discuss the topic:
Software Tools for Embedded Computing: Needs, Solutions and Directions.
TO PARTICIPATE, please submit either one copy of an extended abstract not
exceeding FIVE pages to the following email address or FIVE hard copies to the
program chair at the following address specified. Authors will be notified of a final
decision by November 1st, 1998.
Submission deadline: October 1st, 1998.
E-mail address for submission: CAS...@capsl.udel.edu
Mail address for submission:
Krishna V. Palem
Courant Institute of Mathematical Sciences
251 Mercer Street
New York, NY 10012,
USA.
----------------------------------------------------------------------------------------------
Workshop General Chairs:
Krishna V. Palem (NYU)
Guang R. Gao (Univ. of Delaware)
Local Arrangement Chair:
B. Narahari (The George Washington University)
Workshop Committee:
J. Bondi (TI),
K. Ebciogllu (IBM T. J. Watson Research Center),
Guang R. Gao (U. of Delaware),
Lal George (Lucent Technologies),
Rajiv Gupta (U. of Pittsburgh),
Richard Johnson (HP),
Oded Mahler (Grenoble),
Miroslaw Malek (Humboldt and Stanford Universities),
Krishna Palem (NYU),
Bill Mangione-Smith (UCLA),
John Thornley (Caltech),
Wei Zhao (Rockwell Semiconductor Systems)