64-bit ints on 32-bit platforms

[Michael Day]

Hi,

What would be the best way to manipulate 64-bit integers on 32-bit
platforms?

Presumably on 64-bit platforms one can just use the Mercury int type,
but on 32-bit platforms it would be necessary to make a new type
consisting of two 32-bit ints:

:- type int64 ---> int64(int, int).

Or use a foreign type:

:- pragma foreign_type(c, int64, "int64_t").

In each case, this will result in a 32-bit pointer to a 64-bit integer
being passed to functions or stored in other structures, correct?

I guess what I'm getting at is that it doesn't seem possible to have a
64-bit unboxed value in 32-bit Mercury code, unless the programmer
explicitly stores and passes two 32-bit integers each time, which will
break abstraction and be completely unnecessary on 64-bit platforms.

Is this correct?

Best regards,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Zoltan Somogyi-2]

On 14-Oct-2009, Michael Day <mikeday@...> wrote:
> I guess what I'm getting at is that it doesn't seem possible to have a
> 64-bit unboxed value in 32-bit Mercury code, unless the programmer
> explicitly stores and passes two 32-bit integers each time, which will
> break abstraction and be completely unnecessary on 64-bit platforms.
>
> Is this correct?

Yes. By definition, unboxed values are stored (amongst other places)
in machine registers, and on 32 bit machines, those are (again by definition)
32 bits in size.

Zoltan.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Zoltan,

> Yes. By definition, unboxed values are stored (amongst other places)
> in machine registers, and on 32 bit machines, those are (again by definition)
> 32 bits in size.

In C it is possible to write a function like this:

int64_t foo(int64_t x)
{
     return x + 1;
}

and compile it with gcc for a 32-bit architecture, and it will
transparently use two 32-bit registers for the return value:

foo:
         movl    4(%esp), %eax
         movl    8(%esp), %edx
         addl    $1, %eax
         adcl    $0, %edx
         ret

Presumably the equivalent function in Mercury would need to allocate 8
bytes to store the result value and return the pointer to it, which
seems like it could be costly if lots of arithmetic was being done.

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Zoltan Somogyi-2]

On 16-Oct-2009, Michael Day <mikeday@...> wrote:
> and it will
> transparently use two 32-bit registers for the return value:

Yes. But the Mercury implementation does not do any such thing, for a very
simple reason: it would take a lot of work to implement such a capability,
and the benefit is simply too low. And the benefit is shrinking every day
as the proportion of 64 bit machines in the world is increasing.

> foo:
>         movl    4(%esp), %eax
>         movl    8(%esp), %edx
>         addl    $1, %eax
>         adcl    $0, %edx
>         ret
>
> Presumably the equivalent function in Mercury would need to allocate 8
> bytes to store the result value and return the pointer to it, which seems
> like it could be costly if lots of arithmetic was being done.

By "cost", you mean performance, so that is correct. However, the cost
in programming work of doing what you want would be very high, since the
implication "if a value is unboxed, then its gets stored in a single virtual
machine register which is the same size as an actual machine register" is
embedded very deeply in the compiler and the runtime.

Zoltan.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Zoltan,

> Yes. But the Mercury implementation does not do any such thing, for a very
> simple reason: it would take a lot of work to implement such a capability,
> and the benefit is simply too low. And the benefit is shrinking every day
> as the proportion of 64 bit machines in the world is increasing.

In theory yes, although there are still a lot of 32-bit machines left :)

Hopefully this problem won't reoccur with 128-bit values on 64-bit
machines. (unless people want support for the SSE instructions that
manipulate four floats simultaneously?)

> By "cost", you mean performance, so that is correct. However, the cost
> in programming work of doing what you want would be very high, since the
> implication "if a value is unboxed, then its gets stored in a single virtual
> machine register which is the same size as an actual machine register" is
> embedded very deeply in the compiler and the runtime.

Right.

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[pchapin]

For fun I attempted to compile Mercury on OpenSolaris version 2009.06. My
host CPU is a 32 bit x86 device. Compilation of v0.13.1 seemed to go fine.
The resulting compiler can run at least trivial programs. I didn't try
anything "real" with it. Should I attempt to run the test suite?

Note that OpenSolaris 2009.06 comes with a gcc v3.4.3 package. Thus I did
not attempt to use gcc v4 (which I understand causes problems).

I also tried the ROTD v2009-10-10. That failed. Specifically the
./configure seemed to go fine but when I executed make there were problems
in the boehm_gc directory. It looks like make causes a configure to run in
that directory (is that normal?) and that "nested" configuration can't
locate basic programs like rm, mv, chmod, etc. I suppose there is some
problem with the PATH.

I don't need this fixed. I mostly did this just to pass the time one
evening. I thought I would pass my observations on.

Peter
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------