[M3devel] unaligned procedures closure marker check broken?

[Daniel Alejandro Benavides D.]

Hi all:
but what pointers are you trying to diagnose, if it's a function closure then a REF to a RECORD paired with PROCEDURE is, that is, an OBJECT, but function "tagged" types, I don't think are M3language elements, that doesn't make them BRANDED by default, but structural equivalent by default just different for each type of procedure or method, if you think so, many languages have them,  included C I guess, but why do we need those to build the compiler itself, perhaps object oriented environments can look for those in question, you can look for  a hack B Kallsow tried to do in m3browser with RTType but I guess for structural types not branded types, so perhaps we need them both, it could be a nice work to do in static time, DEC experimented with some HW as a target for Cardelli's typeful Quest language, we could ask more about that experiment, since it targeted Modules static info and we could add everything you want in that.
I need more time to do so, but looks interesting to do.
Thanks in advance

--- El jue, 2/8/12, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] unaligned procedures closure marker check broken?
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 2 de agosto, 2012 02:38




okok..4.5 generates:


    ldx    [%fp+2039], %g1
    and    %g1, 7, %g1
    and    %g1, 0xff, %g1
    cmp    %g1, 0


which is good.
The and 0xff is still pointless.
This is without optimizing.

optimized it is:
    andcc    %i0, 7, %g0
    bne,pn    %xcc, .LL2


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Thu, 2 Aug 2012 07:28:40 +0000
Subject: [M3devel] unaligned procedures closure marker check broken?





Given:


MODULE RTTest; IMPORT RT0;

PROCEDURE F1 (b: RT0.Binder) = BEGIN
EVAL b(0);
END F1;

BEGIN END RTTest.


This tends to fail on Aligned_procedures := FALSE architectures.
I see this testing SPARC64_SOLARIS with gcc 4.7 backend,
when the procedure isn't 8-aligned -- alignment fault.


IL is reasonable:

...
(89)         start_call_indirect type:addr
(90)           load_integer type:int_64 0
(91)           pop_param type:int_64
(92)           load var:0x5 offset:0 src_t:addr dst_t:addr m3name:noname 
(93)           loophole type1:addr type2:int_64
(94)           load_integer type:int_64 7
(95)           and type:int_64
(96)           if_true type:int_64 label:1 frequency:0X32(50)
(97)           load var:0x5 offset:0 src_t:addr dst_t:addr m3name:noname 
(98)           load_nil
...


but the assembly is inefficient and incorrect:


RTTest__F1:
.LLFB0:
    save    %sp, -208, %sp
.LLCFI0:
    stx    %i0, [%fp+2175]
    ldx    [%fp+2175], %g1
    stx    %g1, [%fp+2039]
    ldx    [%fp+2039], %g1
    and    %g1, 7, %g1 <= correct
    and    %g1, 1, %g1  <= incorrect
    and    %g1, 0xff, %g1  <=  pointless, inefficient
    cmp    %g1, 0


current parse.c:


M3CG_HANDLER (IF_TRUE)
{
  tree cond = m3_cast (boolean_type_node, EXPR_REF (-1));
  EXPR_POP ();

  add_stmt (build3 (COND_EXPR, t_void, cond,
                    build1 (GOTO_EXPR, t_void, label),
                    NULL_TREE));
}


static tree
m3_cast (tree type, tree op0)
{
  return m3_build1 (NOP_EXPR, type, op0);
}


Thoughts?


I'm thinking, something like:


PROCEDURE If_closure (proc: Val;  true, false: Label;  freq: Frequency) =
  VAR skip := Next_label ();  nope := skip;
  BEGIN
    IF (false # No_label) THEN  nope := false; END;
    IF NOT Target.Aligned_procedures THEN
      Push (proc);
      Force ();
      cg.loophole (Type.Addr, Target.Integer.cg_type);
      Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
      cg.and (Target.Integer.cg_type);
      
      == insert comparisong to 0 here ==

      cg.if_true (Target.Integer.cg_type, nope, Always - freq);
      SPop (1, "If_closure-unaligned");
    END;
    

and possibly if_true should assert that top of stack is boolean already.


I'll check that this isn't something I broke in 4.7 -- maybe boolean changed.


I was thinking this had something to do with tagged types, but no -- there is nothing
related to them in the IL. I guess function pointers can't be tagged?


 - Jay 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120802/44c08f3d/attachment-0002.html>