[M3devel] m3core/src/types/Unicode.m3 var to const

[Jay K]

"I think I can".

 Just use arrays and indices more and pointers to elements less/not at all.

 

 

Granted, moving the division is a big speed deoptimization since it is no longer by a constant (unless compiler is quite smart and does "partial inlining", and NT386 compiler is not, very few compilers are smart enough to see this).

 

It might be worth a) restoring that small part b) having two functions, one for 2-tuples, one for 3-tuples, or even c) surely we con't need to handcode binary search here in the first place there is some generic reusable version?

But that is tangential to var vs. const.

 

 

I was also considering adding: Int8, UInt8, Int16, UInt16, UInt32, UInt64.

 

In particular, in m3back, I think I'll be using UInt16 in tables -- CodeView 4.0 format uses UINT16 to represent types (CodeView 5.0 uses UINT32).

 

In reality due to padding/alignment, UINT8/16 probably have no space savings, but they will get range checks..but I'll also have to add a range check when I "allocate" a new type. "That" is "why" I was looking in this directory.

 

 - Jay

 


From: hosking at cs.purdue.edu
Date: Tue, 30 Mar 2010 22:39:25 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] m3core/src/types/Unicode.m3 var to const

Yes, I think that looks OK.
The original is very weird M3 code!
Also, can you now make it a safe module instead of UNSAFE?  (No use of ADR anymore).




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



On 30 Mar 2010, at 20:53, Jay K wrote:

This is right, right?
 
 - Jay





<1.txt>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100331/f750e22e/attachment-0002.html>