--
\|/
Thor 2.22 #1497 @ @
+--------------------------oOO-(_)-OOo----------+
| _ // | |
| \X/ |Falkenberg, Westcoast of Sweden |
|A3000/10MB | |
|280HD/28.8 | |
|GVP Spectrum| |
|AFS Pro |Amiga-Programmer in C |
+------------+----------------------------------+
--
Sure. GNU C supports 64 bit ints as type "long long". I.E.:
long l = 0x12345678L;
long long ll = 0x1234567887654321LL;
main ()
{
printf ("sizeof (long) = %d, l = %lx\n",
sizeof (long), l);
printf ("sizeof (long long) = %d, ll = %llx\n",
sizeof (long long), ll);
ll *= l;
}
When compiled by gcc, you get the following code:
#NO_APP
gcc2_compiled.:
___gnu_compiled_c:
.globl _l
.data
.even
_l:
.long 305419896
.globl _ll
.even
_ll:
.long 305419896
.long -2023406815
.text
LC0:
.ascii "sizeof (long) = %d, l = %lx\12\0"
LC1:
.ascii "sizeof (long long) = %d, ll = %llx\12\0"
.even
.globl _main
_main:
link a5,#0
jbsr ___main
movel _l,sp@-
pea 4:w
pea LC0
jbsr _printf
addw #12,sp
movel _ll+4,sp@-
movel _ll,sp@-
pea 8:w
pea LC1
jbsr _printf
addw #16,sp
movel _l,d1
smi d0
extw d0
extl d0
movel d1,sp@-
movel d0,sp@-
movel _ll+4,sp@-
movel _ll,sp@-
jbsr ___muldi3
addw #16,sp
movel d0,_ll
movel d1,_ll+4
moveq #0,d0
jra L1
L1:
unlk a5
rts
When you run this code on a system where the library supports printing
long long types, such as linux, you get:
sizeof (long) = 4, l = 12345678
sizeof (long long) = 8, ll = 1234567887654321
Unfortunately with the current ixemul library implementation when you
run this you get:
sizeof (long) = 4, l = 12345678
sizeof (long long) = 8, ll = 12345678
This is strictly a library issue, the ixemul printf doesn't know how
to print a long long value when given the format "ll". I've looked at
the printf code and it looks like it would be straightforward to add
this support. I will ask Hans to put it on his TODO list. All other
operations that don't involve I/O where it is necessary to convert a
long long value between ascii and binary should work fine.
Actually, I wonder how gcc does it. It probably has built in code
that allows it to read and convert long long constants without using
library support.
-Fred
Actually, the current PPC chips do support 64 bits... just not the buss.
(they have instructions that handle 64 bits of data)
I believe the 620 was going to be... but it's in redesign or
something right now.
James
Yes. Use a DEC Alpha. short = 16-bit, int = 32-bit, long = 64-bit. I don't
think any Amiga compiler support this at the moment though. Should be easy to
do in C++ I guess.
>I'm thinking of the 4.3 GB limit for harddrives and
>are just curious...
Just use an array of two longs until AmigaOS is running on a 64-bit processor.
Aren't later members of the PPC line going to be 64-bit?
--
Ben Hutchings, JCR Computer Rep elect, Worcester College, Oxford.
Finger me as m95...@booth42.ecs.ox.ac.uk for PGP key, geek code, etc.
email: benjamin....@worc.ox.ac.uk WWW: http://users.ox.ac.uk/~worc0223
"I say we take off and nuke the site from orbit. It's the only way to be sure."
>When you run this code on a system where the library supports printing
>long long types, such as linux, you get:
> sizeof (long) = 4, l = 12345678
> sizeof (long long) = 8, ll = 1234567887654321
>Unfortunately with the current ixemul library implementation when you
>run this you get:
> sizeof (long) = 4, l = 12345678
> sizeof (long long) = 8, ll = 12345678
>This is strictly a library issue, the ixemul printf doesn't know how
>to print a long long value when given the format "ll". I've looked at
>the printf code and it looks like it would be straightforward to add
>this support. I will ask Hans to put it on his TODO list. All other
>operations that don't involve I/O where it is necessary to convert a
>long long value between ascii and binary should work fine.
The current ixemul stdio implementation is based on 4.3 BSD code. At the
moment I'm working on ixemul-44.0, which will use NetBSD stdio code and
that implementation does support long longs.
>Actually, I wonder how gcc does it. It probably has built in code
>that allows it to read and convert long long constants without using
>library support.
Yup, it's in the libgcc.a library.
Hans
--
--
Hans Verkuil, Frederik van Eedenplaats 185, 2902 VD Capelle a/d IJssel,
The Netherlands -- Tel: 010-4585745, email: ha...@wyst.hobby.nl
ixemul.library maintainer
"...and the princesses were beautiful as the day is long and so noble they
could pee through a dozen mattresses --" (Terry Pratchett)
>In article <593.6718...@mbox3.swipnet.se>,
>Roland Bengtsson <roland.b...@mbox3.swipnet.se> wrote:
>>Can you define a 64-bit datatype in C, how?
>Yes. Use a DEC Alpha. short = 16-bit, int = 32-bit, long = 64-bit. I don't
>think any Amiga compiler support this at the moment though. Should be easy to
>do in C++ I guess.
>>I'm thinking of the 4.3 GB limit for harddrives and
>>are just curious...
>Just use an array of two longs until AmigaOS is running on a 64-bit
>processor. Aren't later members of the PPC line going to be 64-bit?
Yes, you set a MP mode and everything that before was 32bit now becomes 64bit,
but the 620 is not yet out, and there've been rumors that it has been dropped
because was too much expensive for the small performances improvement than a
604e.
>--
>Ben Hutchings, JCR Computer Rep elect, Worcester College, Oxford.
>Finger me as m95...@booth42.ecs.ox.ac.uk for PGP key, geek code, etc.
>email: benjamin....@worc.ox.ac.uk WWW: http://users.ox.ac.uk/~worc0223
>"I say we take off and nuke the site from orbit. It's the only way to be
>sure."
/-----------------------------------------------------------------------\
| Fabio "Maverick" Bizzetti - bizz...@mbox.vol.it - Maverick* at IRC |
| The maker of "CyberMan" and "Virtual Karting" |
| working on "VirtualRally" & "StarFighter" |
\-----------------------------------------------------------------------/
>:Sure. GNU C supports 64 bit ints as type "long long". I.E.:
>: long l = 0x12345678L;
>: long long ll = 0x1234567887654321LL;
>:Actually, I wonder how gcc does it. It probably has built in code
>:that allows it to read and convert long long constants without using
>:library support.
This means that my SAS/C 6.56 can't do it easily. I have to build
a function that handle this datatype?
Typedef, is this only for <32 bits?
>Actually, the current PPC chips do support 64 bits... just not the buss.
Actually it is the other way round. The chips are 32bit and the bus
is 64bit.
>I believe the 620 was going to be...
The 620 is going to be a 64bit chip with 64bit instructions and
64bit internal operation.
Regards,
--
Michael van Elst
Internet: mle...@serpens.rhein.de
"A potential Snark may lurk in every tree."
Well, I was just looking through several books I have on the PowerPC and
unless I'm mistaken, some 64 bit instructions are listed... I'm not sure
which versions of the chip. And last I knew, Motorolla wasn't anxious
to go to a 64 bit buss on lower end CPU's becouse it didn't offer enough
of a speed up for the cost.
I'll check the books and see what they say.
> >I believe the 620 was going to be...
>
> The 620 is going to be a 64bit chip with 64bit instructions and
> 64bit internal operation.
James
Duo!
I MEANT that some dealt with 64 bit data (say what you mean stupid!)
so now that my foot is out of my mouth, I see that we weren't talking
about the same thing. (and what I meant to say came out totally wrong)
Here was what the books listed.
Instructions are 32 bit.
The data buss is 64 bit with some models having 32/64.
The address buss is 32 bits.
<sigh>
James
"Don't I feal stupid today!"
No, Michael is right. All of the PPC chips (ok, at least the 601, 603, 604,
and 620) have a 64bit internal data bus. I think you are getting confused
with the system bus which would provide little speed up for the cost if it
where 64bit.
--
Steve Hodge
s...@cs.waikato.ac.nz
Computer Science Dept, University of Waikato,
Hamilton, New Zealand
> Actually, I wonder how gcc does it. It probably has built in code
> that allows it to read and convert long long constants without using
> library support.
This is handled in libgcc.a. On targets where CPU does not support 64 bit
integeres (like m68k), emulation is used. This is described in the manual,
I think.
/ Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 1.2 GB, 10 MB RAM \
| is...@student.uci.agh.edu.pl kis...@ernie.icslab.agh.edu.pl |
| http://student.uci.agh.edu.pl/~iskra |
\ PGP public key available via Finger or WWW /
>Yes. Use a DEC Alpha. short = 16-bit, int = 32-bit, long = 64-bit. I don't
>think any Amiga compiler support this at the moment though. Should be easy to
>do in C++ I guess.
MaxonC++ (and thus supposedly StormC++) supports 64-bit variables.
AFAIK gcc does support them, too. Variables of this type are declared
with 'long long'.
--
Andreas E. Bombe | PGP Key Fingerprint: available on
andrea...@munich.netsurf.de | 13 6B BC 15 36 B8 B7 7A request and
| 20 05 58 E8 6F AA F8 ED on homepage
http://home.pages.de/~andreas.bombe/
Zahme Vögel singen von Freiheit... ...wilde Vögel fliegen
Uh, I don't know who is confused, but the currently available PowerPC
models, 601, 603 and 604 have a 64 bit external (that is, CPU<->L2
cache<->RAM) bus and a 32 bit register set. What the CPU internal
_bus_ is, doesn't really matter, and in places its width could even be
40 bits and you wouldn't know. The external bus is wider than the word
size of the CPU for just the same reason the Pentium does the same: to
achieve more memory bandwidth.
Now, just because these CPUs do not have 64 bit registers does not
mean that they could not have instructions that manipulate 64 bits at
once. And, of course, they DO have 64 bit FPU registers.
The 620 (or 630, whatever will come out first) will be the first
processor in the PPC series to be a full 64 bit implementation with 64
bit registers as well.
--
Every silver lining has a cloud around it.
| "Osma Ahvenlampi" <mailto:o...@iki.fi> <http://www.iki.fi/oa/> |
| Amiga&BeBox&ClassAct&Voodoo&ARTech cool stuff: I-Net225&AWeb |
--