Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2302 > unrolled thread

64 bit code

Back to article view | Back to comp.programming

Contents

  64 bit code bob <bob@coolfone.comze.com> - 2012-10-10 08:22 -0700
    Re: 64 bit code Jongware <jongware@no-spam.plz> - 2012-10-10 17:35 +0200
      Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 17:37 +0100
        Re: 64 bit code Robert Wessel <robertwessel2@yahoo.com> - 2012-10-10 12:54 -0500
        Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-10 21:37 +0200
          Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:46 -0500
        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:43 +0100
          Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-12 08:40 +0100
            Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 12:36 -0500
            Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-12 20:57 +0100
              Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-12 21:30 +0100
                Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 16:33 -0500
                  Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 00:44 +0100
                  Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 20:07 -0700
                Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 11:11 +0100
                  Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 13:11 +0100
                    Re: 64 bit code Willem <willem@turtle.stack.nl> - 2012-10-13 12:34 +0000
                      Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-13 09:50 -0500
                      Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 17:25 +0100
                        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:53 +0100
                    Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:05 +0100
            Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-13 10:37 +0200
              Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:18 +0100
                Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:54 +0100
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 15:13 +0200
                  Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-28 04:12 -0500
                    Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-28 13:10 +0100
                      Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-29 04:38 +0000
                        Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-29 09:30 +0100
                          Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:09 +0000
                            Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:47 +0100
                              Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:55 +0100
                              Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:32 +0000
              Re: 64 bit code Patricia Shanahan <pats@acm.org> - 2012-10-27 08:51 -0700
                Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-27 17:23 +0100
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 20:43 +0200
                  Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:16 +0000
                    Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:53 +0100
                      Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:33 +0000
                        Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-01 00:25 +0100
        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 21:04 +0100
          Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 21:52 +0100
            Re: 64 bit code Ian Collins <ian-news@hotmail.com> - 2012-10-11 10:50 +1300
              Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:54 -0500
                Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-11 13:11 +0100
                  Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-11 11:17 -0500
        Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-10 13:17 -0700
          Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-11 19:36 +0200
            Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 08:13 -0700
      Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:38 +0100
      Re: 64 bit code Robin Vowels <robin.vowels@gmail.com> - 2012-10-10 15:22 -0700
    Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-12 02:13 -0500

Page 3 of 3 — ← Prev page 1 2 [3]

#2312

BartC wrote:

> And the downside of 64-bit processors is *having* to use 64-bits for
> things for which 32-bits was perfectly adequate.

Is that really a downside if we can have it all essentially for free?


> They can address over 4GB in one virtual address space, sure, but how 
> many programs actually need to do that?

If a boundary ceases to be there then people start to go through it.  For 
example, I've been developing a number crunching application that 
frequently needs to address more than 4GB of memory.  When I designed it 
I paid no attention to any memory addressing limit because simply there 
isn't one.  If it was there then I would be forced to jump through a 
number of hoops just to go around that limit, and that wouldn't be fun.

I also must be poitned out that the x86-64 ISA brought more to the table 
than a larger address space.  For example, it has twice the number of 
general purpose registers, and they are all 64-bit.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2314

"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:k54kd4$g1o$1@speranza.aioe.org...
> BartC wrote:
>
>> And the downside of 64-bit processors is *having* to use 64-bits for
>> things for which 32-bits was perfectly adequate.
>
> Is that really a downside if we can have it all essentially for free?

But it's not free. You need double the memory bandwidth for a start; you've 
got twice the throughput, but if your data has to be twice as wide, then 
you're back where you started! The stack, for example, might insist on 
64-bit values only, ensuring your data is spread out and requiring more 
accesses.

>> They can address over 4GB in one virtual address space, sure, but how
>> many programs actually need to do that?
>
> If a boundary ceases to be there then people start to go through it.  For
> example, I've been developing a number crunching application that
> frequently needs to address more than 4GB of memory.  When I designed it
> I paid no attention to any memory addressing limit because simply there
> isn't one.  If it was there then I would be forced to jump through a
> number of hoops just to go around that limit, and that wouldn't be fun.

But it might be everyone else who has to jump through hoops, if there isn't 
an easy way of using 32-bit pointers in 64-bit code. And *their* application 
might not involve number-crunching, where the overheads of the calculations 
would hide any manipulations (via an indirect register for example) needed 
to get at the data.

> I also must be poitned out that the x86-64 ISA brought more to the table
> than a larger address space.  For example, it has twice the number of
> general purpose registers, and they are all 64-bit.

When the x86-32 (386) came out, many of the new features could be 
immediately accessed even from 16-bit code, eg. using a d32 prefix to make 
use of 32-bit registers and operations. (Using 32-bit address modes was 
harder without OS support.)

With the x86-64, it seems to be all or nothing: either run everything as 
64-bits, or run in compatible 32-bit mode, where you don't have access to 
the extra, wider registers, nor to 64-bit arithmetic.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2315

On 10/11/12 09:52, BartC wrote:
>
> With the x86-64, it seems to be all or nothing: either run everything as
> 64-bits, or run in compatible 32-bit mode, where you don't have access to
> the extra, wider registers, nor to 64-bit arithmetic.

Which equates to a net loss of nothing and net gain of the 64 bit mode!

Now you have the ability to build and test 32 and 64 bit versions of 
your code to see which performs best.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2318

On 10/10/2012 4:50 PM, Ian Collins wrote:
> On 10/11/12 09:52, BartC wrote:
>>
>> With the x86-64, it seems to be all or nothing: either run everything as
>> 64-bits, or run in compatible 32-bit mode, where you don't have access to
>> the extra, wider registers, nor to 64-bit arithmetic.
>
> Which equates to a net loss of nothing and net gain of the 64 bit mode!
>
> Now you have the ability to build and test 32 and 64 bit versions of
> your code to see which performs best.
>

it is worth noting that there is also the x32 ABI, which is basically a 
32-bit sub-mode of x86-64 (mostly off in Linux land, it is based on the 
SysV/AMD64 ABI).

in this sub-mode, basically the extended registers and arithmetic are 
still available, but there is an ABI-level convention to only use 32-bit 
pointers and stay within the low 4GB of memory.

[toc] | [prev] | [next] | [standalone]

#2319

"BGB" <cr88192@hotmail.com> wrote in message
news:k55cjk$joa$1@news.albasani.net...
> On 10/10/2012 4:50 PM, Ian Collins wrote:
>> On 10/11/12 09:52, BartC wrote:
>>>
>>> With the x86-64, it seems to be all or nothing: either run everything as
>>> 64-bits, or run in compatible 32-bit mode, where you don't have access
>>> to
>>> the extra, wider registers, nor to 64-bit arithmetic.
>>
>> Which equates to a net loss of nothing and net gain of the 64 bit mode!
>>
>> Now you have the ability to build and test 32 and 64 bit versions of
>> your code to see which performs best.
>>
>
> it is worth noting that there is also the x32 ABI, which is basically a
> 32-bit sub-mode of x86-64 (mostly off in Linux land, it is based on the
> SysV/AMD64 ABI).
>
> in this sub-mode, basically the extended registers and arithmetic are
> still available, but there is an ABI-level convention to only use 32-bit
> pointers and stay within the low 4GB of memory.

Is this mode supported by the hardware, or does it depend on software
zero-extending pointers as needed to the 64-bits that are expected?

I suspect the latter, from what I have been able to find out.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2325

On 10/11/2012 7:11 AM, BartC wrote:
>
>
> "BGB" <cr88192@hotmail.com> wrote in message
> news:k55cjk$joa$1@news.albasani.net...
>> On 10/10/2012 4:50 PM, Ian Collins wrote:
>>> On 10/11/12 09:52, BartC wrote:
>>>>
>>>> With the x86-64, it seems to be all or nothing: either run
>>>> everything as
>>>> 64-bits, or run in compatible 32-bit mode, where you don't have access
>>>> to
>>>> the extra, wider registers, nor to 64-bit arithmetic.
>>>
>>> Which equates to a net loss of nothing and net gain of the 64 bit mode!
>>>
>>> Now you have the ability to build and test 32 and 64 bit versions of
>>> your code to see which performs best.
>>>
>>
>> it is worth noting that there is also the x32 ABI, which is basically a
>> 32-bit sub-mode of x86-64 (mostly off in Linux land, it is based on the
>> SysV/AMD64 ABI).
>>
>> in this sub-mode, basically the extended registers and arithmetic are
>> still available, but there is an ABI-level convention to only use 32-bit
>> pointers and stay within the low 4GB of memory.
>
> Is this mode supported by the hardware, or does it depend on software
> zero-extending pointers as needed to the 64-bits that are expected?
>
> I suspect the latter, from what I have been able to find out.
>


it is implemented in software, but it does make use of a little quirk 
that exists in x86-64, namely that whenever a 32-bit operation is 
performed, the register is automatically zero-extended. this allows the 
code to essentially largely ignore the upper 32-bits, which are then 
basically automatically cleared by any arithmetic ops.

there are a few cases where things may need to be handled specially, as, 
since the CPU doesn't actually "know" that the space is supposed to 
wraparound after 4GB, it is possible for code to "accidentally" go 
outside the 4GB window in certain cases.

this can generally be handled by using an extra step using a register 
(we load the target address in a register and then use this to access 
memory, rather than doing it directly).


or such...

[toc] | [prev] | [next] | [standalone]

#2313

"BartC" <bc@freeuk.com> writes:

> And the downside of 64-bit processors is *having* to use 64-bits for
> things for which 32-bits was perfectly adequate.
>
> They can address over 4GB in one virtual address space, sure, but how
> many programs actually need to do that?

This is why Linux on x86 now has the "x32" ABI that runs in
64-bit mode but only uses 32 bits of address space.

[toc] | [prev] | [next] | [standalone]

#2326

Ben Pfaff <blp@cs.stanford.edu> wrote:

> "BartC" <bc@freeuk.com> writes:
> 
> > And the downside of 64-bit processors is *having* to use 64-bits for
> > things for which 32-bits was perfectly adequate.
> >
> > They can address over 4GB in one virtual address space, sure, but how
> > many programs actually need to do that?
> 
> This is why Linux on x86 now has the "x32" ABI that runs in
> 64-bit mode but only uses 32 bits of address space.

But I heard this doesn't really work

[toc] | [prev] | [next] | [standalone]

#2329

Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net>
writes:

> Ben Pfaff <blp@cs.stanford.edu> wrote:
>
>> "BartC" <bc@freeuk.com> writes:
>> 
>> > And the downside of 64-bit processors is *having* to use 64-bits for
>> > things for which 32-bits was perfectly adequate.
>> >
>> > They can address over 4GB in one virtual address space, sure, but how
>> > many programs actually need to do that?
>> 
>> This is why Linux on x86 now has the "x32" ABI that runs in
>> 64-bit mode but only uses 32 bits of address space.
>
> But I heard this doesn't really work

Cite?  I don't know of a reason why it shouldn't work.

(But the x32 ABI is very new, so it's possible that some wrinkles
are not yet ironed out.)

[toc] | [prev] | [next] | [standalone]

#2310

Jongware wrote:

> One compelling reason could be that Bigger = Better. A native 64 bit
> processor can handle integers up to 2^64 ~ 10^19, which admittedly is
> not a big advantage (I don't think an integer of such size is useful 
for
> arithmetic), but they also can process 64 bit floating point numbers in
> one stride. As far as floating point goes, bigger (more precision!) is
> most definitely better.

Not quite.  There is a significant tradeoff between the computational 
cost of an algorithm and the precision of the floating point data type 
that is used.  In a significant number of number crunching applications, 
the double precision type brings an insignificant improvement in 
accuracy.  Being forced to waste more time crunching some numbers to end 
up with practically the exact same result is something which pretty much 
everyone wants to avoid.  

So no, greater precision is not always better, and can actually be worse.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2316

On Oct 11, 2:35 am, Jongware <jongw...@no-spam.plz> wrote:
> On 10-Oct-12 17:22 PM, bob wrote:
>
> > Was the move to 64 bit code primarily to break the 4 gig memory barrier?
>
> > Or were there other equally compelling incentives?
>
> Memory is typically served by a separate bus. There used to be 16/32 bit
> CPUs that internally worked with 16 bit words and externally with 32
> bits (or possibly the other way around).
>
> One compelling reason could be that Bigger = Better. A native 64 bit
> processor can handle integers up to 2^64 ~ 10^19, which admittedly is
> not a big advantage (I don't think an integer of such size is useful for
> arithmetic), but they also can process 64 bit floating point numbers in
> one stride. As far as floating point goes, bigger (more precision!) is
> most definitely better.

64-bit floating-point numbers have been available from early PC days
(without 64-bit processor).  If you mean FPNs stored in 64-bit form,
they have been around since the 1960s.
FPNs with 64-bit mantissa are part of the PC's FPU, whereby each
FPN is requires 80 bits.
None of those required 64-bit processor.

[toc] | [prev] | [next] | [standalone]

#2327

On 10/10/2012 10:22 AM, bob wrote:
> Was the move to 64 bit code primarily to break the 4 gig memory barrier?
>
> Or were there other equally compelling incentives?

Some of the server versions of Windows used a different method to get 
past the
4 gig memory barrier - using two registers to hold a complete memory 
address,
not just one.

Some of the early 8-bit processors used a similar method to get past the 256
byte barrier, and make the new barrier 64 k for two registers, or higher 
for three.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.programming

csiph-web