128-bit evaluator?

Okay, just to throw another messy bit of stuff in the
mix...

I have been wondering for a few days if it wouldn't make
sense for the 
evaluator to be either 128 bits or arbitrarily wide.  The
latter is 
really expensive, though, but 128 bits should be enough.  It
would deal 
with the issue of integer constants in "dt" and
"do", and would also 
make the handling of __float80__ and __float128__ much
cleaner.  The 
downside, of course, is that multiprecision math is more
expensive, and 
that we'd have to hack it into more places.

Keith -- you're the one who has touched this code most
recently.  What 
would your assessment be on this?

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

H. Peter Anvin wrote:
> Okay, just to throw another messy bit of stuff in the
mix...
>
> I have been wondering for a few days if it wouldn't
make sense for the 
> evaluator to be either 128 bits or arbitrarily wide. 
The latter is 
> really expensive, though, but 128 bits should be
enough.  It would deal 
> with the issue of integer constants in "dt"
and "do", and would also 
> make the handling of __float80__ and __float128__ much
cleaner.  The 
> downside, of course, is that multiprecision math is
more expensive, and 
> that we'd have to hack it into more places.
>
> Keith -- you're the one who has touched this code most
recently.  What 
> would your assessment be on this?
>
> 	-hpa
>   

I would opt for 128 bits, as it crossed my mind when
upgrading the 
evaluator and definitely should be sufficient until we hit
the x86-128 
architecture :P

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

On Thu, 18 Oct 2007 21:51:28 -0500
Keith Kanios <keithkanios.net> wrote:

> I would opt for 128 bits, as it crossed my mind when
upgrading the 
> evaluator and definitely should be sufficient until we
hit the
> x86-128 architecture :P

I agree. I do not see enough benefit to justify the work of
going to
arbitrary precision.

-- Chuck

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

> > I would opt for 128 bits, as it crossed my mind
when upgrading the
> > evaluator and definitely should be sufficient
until we hit the
> > x86-128 architecture :P
>
> I agree. I do not see enough benefit to justify the
work of going to
> arbitrary precision.

I disagree, for three reasons.

First, it will reduce performance on all platforms (until
someone actually starts supporting 128-bit integers).
Which sucks: the recent transition to 64-bit machines
finally made long long performance acceptable; now
you're gonna ruin it again. Not good.

Second, with NASM being written in C, C essentially
is the bellwether. It has not gotten any 128-bit integer
support yet; when it gets that -- and only then -- does
it seem time to update NASM.

Third, there does not seem to be any 128-bit integer
support on the x86 horizon. Or that of any other ISA.
In fact, it is unlikely that address spaces will exceed
64 bits. That said, going to 128 bits just for DT or DO
doesn't seem like the right thing.

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

anonymous coward wrote:
>>> I would opt for 128 bits, as it crossed my mind
when upgrading the
>>> evaluator and definitely should be sufficient
until we hit the
>>> x86-128 architecture :P
>> I agree. I do not see enough benefit to justify the
work of going to
>> arbitrary precision.
> 
> I disagree, for three reasons.
> 
> First, it will reduce performance on all platforms
(until
> someone actually starts supporting 128-bit integers).
> Which sucks: the recent transition to 64-bit machines
> finally made long long performance acceptable; now
> you're gonna ruin it again. Not good.
> 
> Second, with NASM being written in C, C essentially
> is the bellwether. It has not gotten any 128-bit
integer
> support yet; when it gets that -- and only then --
does
> it seem time to update NASM.
> 
> Third, there does not seem to be any 128-bit integer
> support on the x86 horizon. Or that of any other ISA.
> In fact, it is unlikely that address spaces will
exceed
> 64 bits. That said, going to 128 bits just for DT or
DO
> doesn't seem like the right thing.
> 

128-bit integers are already supported in some MIPS
derivatives (the PS2 
one, in particular); I wouldn't be all that surprised if a
full set of 
"DQ" integer operations are introduced in SSE6+ at
some point.

The other thing to keep in mind is that the cost of
multiprecision 
arithmetic is small compared to the parsing overhead,
*EXCEPT* for 
multiplication and (especially) division.

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

Keith Kanios wrote:
> H. Peter Anvin wrote:
>> Okay, just to throw another messy bit of stuff in
the mix...
>>
>> I have been wondering for a few days if it wouldn't
make sense for the 
>> evaluator to be either 128 bits or arbitrarily
wide.  The latter is 
>> really expensive, though, but 128 bits should be
enough.  It would 
>> deal with the issue of integer constants in
"dt" and "do", and would 
>> also make the handling of __float80__ and
__float128__ much cleaner.  
>> The downside, of course, is that multiprecision
math is more 
>> expensive, and that we'd have to hack it into more
places.
>>
>> Keith -- you're the one who has touched this code
most recently.  What 
>> would your assessment be on this?
> 
> I would opt for 128 bits, as it crossed my mind when
upgrading the 
> evaluator and definitely should be sufficient until we
hit the x86-128 
> architecture :P

Note this wasn't an either/or... there are pretty much three
answers: 64 
bits (current), 128 bits, and full bignum.

I looked at it briefly, and it looks like there is a fair
bit of work 
that would have to be done to support a
"non-native" number size... at 
least unless we go to C++ and implement it as a class (since
we can then 
use operator overloading to mimic traditional numbers.)

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

H. Peter Anvin wrote:
> Keith Kanios wrote:
>> H. Peter Anvin wrote:
>>> Okay, just to throw another messy bit of stuff
in the mix...
>>>
>>> I have been wondering for a few days if it
wouldn't make sense for 
>>> the evaluator to be either 128 bits or
arbitrarily wide.  The latter 
>>> is really expensive, though, but 128 bits
should be enough.  It 
>>> would deal with the issue of integer constants
in "dt" and "do", and 
>>> would also make the handling of __float80__ and
__float128__ much 
>>> cleaner.  The downside, of course, is that
multiprecision math is 
>>> more expensive, and that we'd have to hack it
into more places.
>>>
>>> Keith -- you're the one who has touched this
code most recently.  
>>> What would your assessment be on this?
>>
>> I would opt for 128 bits, as it crossed my mind
when upgrading the 
>> evaluator and definitely should be sufficient until
we hit the 
>> x86-128 architecture :P
>
> Note this wasn't an either/or... there are pretty much
three answers: 
> 64 bits (current), 128 bits, and full bignum.
>
> I looked at it briefly, and it looks like there is a
fair bit of work 
> that would have to be done to support a
"non-native" number size... at 
> least unless we go to C++ and implement it as a class
(since we can 
> then use operator overloading to mimic traditional
numbers.)
>
>     -hpa
>
>
>

I understood what you meant, and I still would suggest fixed
128-bit 



------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

Keith Kanios wrote:

...
> I understood what you meant, and I still would suggest
fixed 128-bit 

I would've thought 64 bits was "enough for
anybody". But then, I thought 
8 bits was enough...

I noted, browsing the links to the elf specs that Peter
posted (without 
much enlightenment, yet) that the number 128 appeared a lot
in the DWARF 
material... if that's an argument in favor...

Best,
Frank

P.S. Big thanks to Chuck for quieting those warnings -
especially the 
"datadir" thingie! Down to:

output/outcoff.c: In function `coff_write_symbols':
output/outcoff.c:848: warning: comparison between signed and
unsigned
output/outobj.c: In function `obj_write_file':
output/outobj.c:2000: warning: comparison between signed and
unsigned

And a few in the rdoff stuff...


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

Frank Kotler wrote:
> 
> I noted, browsing the links to the elf specs that Peter
posted (without 
> much enlightenment, yet) that the number 128 appeared a
lot in the DWARF 
> material... if that's an argument in favor...
> 

DWARF has a funny encoding format for numbers, which we'd
probably want 
to be able to support either via a macro or via an operator.
 I think it 
can simply be done via a macro, but I'm not 100% sure.

The 128-bit number is simply an observation that that is the
size of the 
largest object in the current x86 architecture.

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

> The 128-bit number is simply an observation that that
is the size of the
> largest object in the current x86 architecture.

While XMM operates on 128-bit objects, those are composed
of items no wider than 64 bits. That said, the widest
objects at
this time are 80-bit EP FP and 80-bit BCD numbers (and they
are restricted to memory, i.e. DT).

Intel's Larrabee might introduce 128-bit integer and/or
128-bit
FP support, but other than that nothing wide appears to be
on
the x86 horizon for the next 3-4 years.

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel