[M3devel] Integer literals

[Jay K]

Hm..these hardware conversions..yeah they do exist.

But they are fast and lossless.

Depending on the instruction set, they aren't even avoidable.

  e.g. x86 I think usually does double arithmetic.

        68K maybe extended.

But to be clear, they tend to be a single instruction each, load or move.

Every INTEGER can be represented in a LONGINT, by sign extension.

Every REAL can be represented as LONGREAL. 

And you know, INTEGER MOD INTEGER on IA64 uses conversion to floating point?

 I was surprised by that actually, stepping through some hash table code,

   but it is just the way it is. There's I guess no integer division and

   the floating point is done with 64 or more bits of precision, so it works.

 

 

As long as conversion is fast and lossless..?

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:51:17 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Integer literals




No!  You're missing my whole point about representation.  With what you are proposing here for the float types you will end up with implicit conversion operations performed in the hardware.  The whole idea with explicit conversions is that programmers don't end up coding something that they have not transparently written.  That is a fundamental and highly-valued design principle with Modula-3.  We are not trying to reinvent C here.


On 10 Jan 2010, at 15:43, Jay K wrote:

Seems fine either way.
Assignability gives us, which we were missing before, VAR a:LONGINT := 0;



 > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
 > do have incompatible value representations).
 
 
I keep seeing this and am surprised.
Isn't it the case that REAL <= LONGREAL <= EXTENDED
in terms of precision and range?
LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not); 
 
And then, if that is true, mixing should be allowed..widen any constituents
in an expression to the widest type.
 
 
I realize mixing floating point and integer is less natural, nothing about
floating point is natural really, though on a 32bit platform
LONGREAL can hold all INTEGERS..

 - Jay

 


From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 15:23:28 -0500
To: m3devel at elegosoft.com
Subject: [M3devel] Integer literals


One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
(Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).


It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)


Here's how things would work with subrange types.


A subrange written as currently


[lo .. hi]


would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.


A subrange with base type LONGINT would be written explicitly:



[lo .. hi] OF LONGINT



The constants lo/hi must both be in range for LONGINT.


We could also support the form:




[lo .. hi] OF INTEGER


just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.


Here we are allowing the programmer to state explicitly what the base type of the subrange should be.


Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.



Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office   +1 765 494 6001  +1 765 494 6001    +1 765 494 6001  +1 765 494 6001  | Mobile   +1 765 427 5484  +1 765 427 5484    +1 765 427 5484  +1 765 427 5484 


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/cf8634f8/attachment-0002.html>