[M3devel] LONGINT -> more bugs in m3tk

[Daniel Alejandro Benavides D.]

Hi all:
how does the arithmetic of LONGREAL affects that of the LONGINT, since both depend on that every BITSIZE should have comparable sizes, shouldn't it? 
I mean opaque types must be declared in both size LONGINT type and/or INTEGER size(s) to be able to be instantiated from memory in FPU in both cases, I know x87 is bigger size for its integers, besides what happens if the system doesn't provide that, should one consider implementing all (the) type conversions? Here:
http://modula3.elegosoft.com/cm3/doc/reference/real-intf.html

I think this one lets open the door for such conversions if I may say so:
http://modula3.elegosoft.com/cm3/doc/reference/arithmetic.html

I know one of the annoyances of old x86 FPU was to make any format conversion to CPU arithmetic thus converting from floats was very onerous in terms of losing your maximized precision in one assignment and bigger performance issues which made impractical for both sides, since initially every cycle was different and so, but I guess all programmer must be aware of that, but if the systems provide better performance like in any reasonable bigger machine, why not? I will give a check of decndumber to seek if they do that at least they had elegant exception handling

Thanks in advance

--- El mar, 26/4/11, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] LONGINT -> more bugs in m3tk
> Para: m3devel at elegosoft.com
> Fecha: martes, 26 de abril, 2011 14:50
> 
> 
> On 04/26/2011 11:28 AM, Rodney M. Bates wrote:
> > I just checked in a patch tp M3CExpValue.m3 in m3tk,
> in the head, which I believe will fix this
> > bug. I compiled it, but have not tested it, as I am
> sure Mika has this case to retry
> > more quickly than I can.
> >
> 
> P.S.:  Hats off to whoever adapted m3tk for
> LONGINT.  There are places _everywhere_ that needed
> modification.  The whole thing is about as pedantic as
> code gets.  Layers upon layers of
> linguistic abstractions that do mostly zero semantic
> abstraction.  I traced two declarations
> through 10 levels each of referrals to other interfaces,
> all but one of them just renames
> with the same simple name and different qualifying
> interfaces, before finally getting to
> something with some meat.
> 
> The whole thing smells very strongly of the Ada/Diana
> culture of ASTs.
> 
> > On 04/19/2011 06:51 AM, Mika Nystrom wrote:
> >> Hello m3devel,
> >>
> >> If anyone knows how to fix the following
> trivially, please go ahead.
> >>
> >>
> "/usr/local/cm3/pkg/m3core/src/C/64BITS/BasicCtypes.i3",
> line 18,45: type error in arguments to binary operator
> >>
> "/usr/local/cm3/pkg/m3core/src/C/64BITS/BasicCtypes.i3",
> line 18,25: bad numeric literal
> >>
> "/usr/local/cm3/pkg/m3core/src/C/64BITS/BasicCtypes.i3",
> line 18,51: bad numeric literal
> >>
> >> (errors reported by m3tk).
> >>
> >> The offending line is:
> >>
> >> INTERFACE BasicCtypes;
> >>
> >> IMPORT Word, Long;
> >>
> >> TYPE
> >> (* the four signed integer types *)
> >> signed_char = [-16_7f-1 .. 16_7f];
> >> short_int = [-16_7fff-1 .. 16_7fff];
> >> int = [-16_7fffffff-1 .. 16_7fffffff];
> >> long_int = [-16_7fffffffffffffff -1 ..
> 16_7fffffffffffffff ];
> >> long_long = [-16_7fffffffffffffffL-1L ..
> 16_7fffffffffffffffL]; (** HERE **)
> >>
> >> (* the four unsigned integer types *)
> >> unsigned_char = [16_0 .. 16_ff];
> >> unsigned_short_int = [16_0 .. 16_ffff];
> >> unsigned_int = [16_0 .. 16_ffffffff];
> >> unsigned_long_int = Word.T;
> >> unsigned_long_long = Long.T;
> >>
> >> (* the three floating types *)
> >> float = REAL;
> >> double = LONGREAL;
> >> long_double = EXTENDED;
> >>
> >> (* char *)
> >> char = signed_char;
> >>
> >> END BasicCtypes.
> >>
> >> I'll look at it myself, but not immediately (no
> time). Workaround for now.
> >>
> >> Mika
> >>
> >
>