[M3devel] m3_load/m3_store/bit_field_ref lose offset??

Tony Hosking hosking at cs.purdue.edu
Sun Dec 14 07:23:06 CET 2008


I thought module globals *were* declared as a struct -- it's been a  
while...

On 14 Dec 2008, at 16:53, Jay wrote:

> I tried getting C to error this way, and failed.
> It looks like C uses COMPONENT_REF here, which will send it down  
> different paths I didn't follow.
> COMPONENT_REF makes sense for it and only somewhat sense for us.
> That would involve declaring all of a module's globals a struct,  
> which I don't believe we currently do but might be good. I think  
> there's a basic disconnect in that in C, bitfields are always  
> fields, never freestanding. Modula-3 rather violates that. Seems a  
> little dangerous therefore to be using them this way?
>
> In terms of the inefficient option in parse.c, that would maybe go  
> away, as all the offseting would be handled by the next level down,  
> like, implementation of fields?
> Well..that is assuming the only use offset != 0 in m3_load is for  
> accessing module globals. I don't know if that is true.
>
> Maybe another option, should be easy to implement but might compile  
> slowly, is to cons up a field decl right there in m3_load/store?  
> That would lead to a lot of extra nodes -- per access instead of  
> declared once. I can try that out.
>
>  - Jay
>
>
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] m3_load/m3_store/bit_field_ref lose offset??
> Date: Sat, 13 Dec 2008 18:03:08 +0000
>
> I've just spent a few hours debugging this.
>
> The problem is strongly related to the declaration that the global  
> segment is of size BIGGEST_ALIGNMENT.
> gcc decides they can fit in a register..so then it doesn't bother  
> adding the offset to the address, something like that.
>
> When things work, it goes here:
>  op0 = adjust_address (op0, mode1, offset);
> in expr.c. When things don't work, that line is skipped and then  
> shortly below that:
>
>       if (mode1 != mode)
>  return convert_to_mode (tmode, op0, unsignedp);
>       return op0;  <<
>
> On systems where BIGGEST_ALIGNMENT fits in a register, e.g.  
> apparently MIPS, counter-e.g. apparently many others, but not  
> clearly all others. This determines whether the mode of the segment  
> is SImode (32bit integer), DImode (64bit integer) or BLKmode (larger  
> than any machine type?). BLKmode works. It works on 32bit MIPS  
> because between mode1 and mode, one of them is SImode, one is  
> DImode. On x86/AMD64/PowerPC systems, I expect it is BLKmode, since  
> biggest alignment is set very large -- 128. I don't know why it  
> works for SPARC.
>
> PERHAPS I can put together a C or treelang example and get more (gcc  
> developers) eyes on it, but I doubt it.
>
> The following hack works around it:
>
> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\m3cg>cvs -z3 diff parse.c
> Index: parse.c
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v
> retrieving revision 1.77
> diff -r1.77 parse.c
> 2865c2865
> <     = m3_build_type (T_struct, BIGGEST_ALIGNMENT,  
> BIGGEST_ALIGNMENT);
> ---
> >     = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2,  
> BIGGEST_ALIGNMENT);
>
> The repro is very easy.
> Just add this to m3core:
>
> MODULE Main2 EXPORTS Main;
> IMPORT RTIO;
> VAR a := "a";
> BEGIN
>   RTIO.PutText(a);
> END Main2.
>
> The load of a will be from MM_Main2 offset 0, instead of 104 or  
> thereabouts.
>
> I'll commit this shortly.
>
>  - Jay
>
>
>
>
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 13 Nov 2008 00:04:32 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3_load/m3_store/bit_field_ref lose offset??
>
>  > Jay, do you have access to an AMD64_DARWIN box?
>
> No, sorry, I don't yet and not sure when I will.
> Unless it is easy enough to run on non-Apple hardware.
> I'll have to debug it (m3cg) then.
>
>  - Jay
>
>
>
>
>
>
>
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] m3_load/m3_store/bit_field_ref lose offset??
> Date: Wed, 12 Nov 2008 20:46:53 +0000
>
> Jay, do you have access to an AMD64_DARWIN box?   I did get things  
> working on that 64-bit platform.   Or is it an endianness issue you  
> are dealing with.  In any case, I will not have a lot of bandwidth  
> for doing much in the way of tackling this unless it becomes  
> critical path for me soon.
>
>
>
> 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 12 Nov 2008, at 07:57, Jay wrote:
>
> Target.Little_endian is used to drive some target-specificity in the  
> IR.
>    I guess, after all, that is why you have to specify it.
>
> The IR for RTLinker.m3 is identical for MIPS64_OPENBSD and  
> SPARC64_SOLARIS, once I set them both to unaligned_procedures, which  
> they both need. (Tangent, I ran m3cgcat on the .ms file a few times  
> instead of the .mc file; that makes it crash.)
>
> I can't claim SPARC64_SOLARIS is any paragon of working and correct  
> though, by far.
> I should also be able to compare with SPARC64_OPENBSD, I forgot  
> about that, and didn't have an m3cg.
> I only ran SPARC64_SOLARIS far enough to discover it needed  
> unaligned procedures.
> I think I should fork linux-common and solaris-common off of the  
> minimal 29k openbsd-common, rather than worry about all the stuff in  
> solaris-2-x and linux-libc, over 100k each. Then SPARC64_SOLARIS  
> could/would be in better shape probably.
>
> MIPS64_OPENBSD cm3 gets further with unaligned_procedures, along  
> with the parse.c fix -- it gets to a bus error in RunMainBody.
> Again an alignment problem, though I think maybe memory memory  
> trashing.
> The fault occurs here:
>
>     desc_offset := init_depth * ADRSIZE (InitDesc);
>
>       desc := init_stack + desc_offset;
>       init_depth := desc.low_link; <<
>
>   InitDesc = RECORD
>     module   : RT0.ModulePtr;
>     low_link : INTEGER;
>   END;
>
> desc_offset appears to not be a multiple of 4.
>
> I will look into that.
>
> Long story short -- consider again the parse.c change?
> I admit I still haven't debugged it (or rather, the code that  
> consumes the data produced by it).
>
>  - Jay
>
>
>
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] m3_load/m3_store/bit_field_ref lose offset??
> Date: Sun, 9 Nov 2008 11:10:54 +0000
>
> I agree. I am suspicious too. I will investigate more. Thanks.
>
>  - Jay
>
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Sun, 9 Nov 2008 10:01:58 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3_load/m3_store/bit_field_ref lose offset??
>
>
>
> Aren't the integer values supposed to be written endian- 
> independently in the IR?  I am suspicious about these differences.
>
> On 9 Nov 2008, at 01:25, Jay wrote:
>
> Thanks for the tip/direction.
>
> Uncertain -- m3cgcat between AMD64_LINUX and MIPS64_OPENBSD are "the  
> same" but for two systematic diffs:
>
>  - AMD64_LINUX has a bunch of added calls to check_nil.
>    This is a "bug" in it, inoptimal but ok code, because "first  
> readable address" is 0. It should probably be 4k. I should write a  
> program that iterates starting at 0 to find the value.
>   (or better yet, cm3 should have a -configure option that does  
> this? -- for configuration values for which there is a safe default;  
> in general, imho, the targets should be auto configured via C,  
> assuming there is a native development environment available).
>
>  - some integers are different (again, systematically)
>
> AMD64_LINUX:
>  init_int  656 13 Int.64
>  init_chars  664 "    typecode "
>  init_int  680 2 Int.64
>  init_var  688 v.1 0
>  init_int  696 13 Int.64
>  init_chars  704 "    typeid   "
>  init_int  720 2 Int.64
>  init_var  728 v.1 0
>  init_int  736 13 Int.64
>  init_chars  744 "RunMainBody: "
>  init_int  760 2 Int.64
>  init_var  768 v.1 0
>  init_int  776 19 Int.64
>  init_chars  784 "RunMainBody: exec: "
>  init_int  808 2 Int.64
>  init_var  816 v.1 0
>  init_int  824 17 Int.64
>  init_chars  832 "ExpandInitStack: "
>
> MIPS64_OPENBSD:
>
>  init_chars  664 "    typecode "
>  init_int  680 8796093022208 Int.64
>  init_var  688 v.1 0
>  init_int  696 13 Int.64
>  init_chars  704 "    typeid   "
>  init_int  720 8796093022208 Int.64
>  init_var  728 v.1 0
>  init_int  736 13 Int.64
>  init_chars  744 "RunMainBody: "
>  init_int  760 8796093022208 Int.64
>  init_var  768 v.1 0
>  init_int  776 19 Int.64
>  init_chars  784 "RunMainBody: exec: "
>  init_int  808 8796093022208 Int.64
>  init_var  816 v.1 0
>
> This 8796093022208 is 80000000000 aka 0000_0800_0000_0000, where  
> little endian has 2.
>
> I don't know what these numbers represent.
> I should look at other systems -- preferably a working 64 bit big  
> endian system, if there are any.
>
> Could be flags/type with text literals?
>
> (Btw, I always leave the TextLiteral.i3 change on my system,  
> lowering the maximum literal length to around 4gig even on 64 bit  
> targets, so 32 bit can bootstrap 64 bit...need to fix the compiler  
> here to do target arithmetic instead of host arithmetic...)
>
> Thanks,
>  - Jay
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Sat, 8 Nov 2008 22:55:54 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3_load/m3_store/bit_field_ref lose offset??
>
> Have you checked to make sure that the pre-gcc IR makes sense?  Does  
> it see these values as 32-bit or 64-bit?  The reason I ask is that  
> there may be something wrong in your m3middle target specs that  
> cause bad IR.  Once we know the IR looks right then we can try and  
> fix the problem.
>
> 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 8 Nov 2008, at 15:45, Jay wrote:
>
>
> truncated as usual...along with losing a lot of whitespace..
> Let's see...
>
>
> Tony, how about switching these #if's?
> I explain some of why below.
>
> static void
> m3_store (tree v, int o, tree src_t, m3_type src_T, tree dst_t,  
> m3_type dst_T)
> {
>  tree val;
> #if 0
>  if (o != 0 || TREE_TYPE (v) != dst_t) {
>    v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>     bitsize_int (o));
>  }
> #else
>  /* failsafe, but inefficient */
>  if (o != 0 || TREE_TYPE (v) != dst_t) {
>    v = m3_build1 (ADDR_EXPR, t_addr, v);
>    v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>    v = m3_build1 (INDIRECT_REF, dst_t,
>     m3_cast (build_pointer_type (dst_t), v));
>  }
> #endif
>  TREE_THIS_VOLATILE (v) = 1; /* force this to avoid aliasing  
> problems */
>  val = m3_cast (src_t, EXPR_REF (-1));
>  if (src_T != dst_T) {
>    val = m3_build1 (CONVERT_EXPR, dst_t, val);
>  }
>  add_stmt (build2 (MODIFY_EXPR, dst_t, v, val));
>  EXPR_POP ();
> }
> m3_load (tree v, int o, tree src_t, m3_type src_T, tree dst_t,  
> m3_type dst_T)
> {
> #if 0
>  if (o != 0 || TREE_TYPE (v) != src_t) {
>    v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>     bitsize_int (o));
>  }
> #else
>  /* failsafe, but inefficient */
>  if (o != 0 || TREE_TYPE (v) != src_t) {
>    v = m3_build1 (ADDR_EXPR, t_addr, v);
>    v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>    v = m3_build1 (INDIRECT_REF, src_t,
>     m3_cast (build_pointer_type (src_t), v));
>  }
> #endif
>  TREE_THIS_VOLATILE (v) = 1; /* force this to avoid aliasing  
> problems */
>  if (src_T != dst_T) {
>    v = m3_build1 (CONVERT_EXPR, dst_t, v);
>  }
>  EXPR_PUSH (v);
> }
>
> I'm working on MIPS64_OPENBSD (OpenBSD on an SGI O2).
> In an early version it seems that many loads/stores of global  
> variables is wrong.
> The "first" code affected is RTLinker_ExpandModuleTable.
>
> PROCEDURE ExpandModuleTable () =
>  CONST InitialTableSize = 500;
>  VAR new_mods: ADDRESS;  n_bytes: INTEGER;
>  BEGIN
>    IF (modules = NIL) THEN
>      (* first time... *)
>      max_modules := InitialTableSize;
>      modules := Cstdlib.malloc (InitialTableSize * BYTESIZE  
> (RT0.ModulePtr));
>      IF (modules = NIL) THEN Cstdlib.abort (); END;
>    ELSE
>      n_bytes := max_modules * BYTESIZE (RT0.ModulePtr);
>      new_mods := Cstdlib.malloc (n_bytes + n_bytes);
>      IF (new_mods = NIL) THEN Cstdlib.abort (); END;
>      EVAL Cstring.memcpy (new_mods, modules, n_bytes);
>      Cstdlib.free (modules);
>      modules := new_mods;
>      INC (max_modules, max_modules);
>    END;
>  END ExpandModuleTable;
>
> It should read back modules as NIL.
> What happens is it reads back modules as not NIL,
> and then max_modules should also be zero, but is "large", leading to  
> malloc to fail,
> and abort called.
>
> The output of cm3cg -y is reasonable.
> It indicates offset loads.
>
> What is incorrect is that in many loads and stores, but not all, the
> offsets are lost.
>
> (923) begin_procedure
>  procedure RTLinker__ExpandModuleTable
> RTLinker__ExpandModuleTable(924) set_source_line
>  source line  208
> (925) load_nil
> (926) store
>  store (M3_AJWxb1_new_mods) offset 0x0 src_t 0xb dst_t 0xb
> (927) set_source_line
>  source line  207
> (928) set_source_line
>  source line  210
> (929) load_nil
> (930) load
>  m3cg_load (MM_RTLinker): offset 0x440, convert 0xb -> 0xb
>
> Here is the incorrect code:
>
> .globl RTLinker__ExpandModuleTable
> .stabd 46,0,0
> .stabn 68,0,206,.LM108
> .LM108:
> .LFBB8:
> .set nomips16
> .ent RTLinker__ExpandModuleTable
> RTLinker__ExpandModuleTable:
> .frame $fp,64,$31  # vars= 32, regs= 3/0, args= 0, gp= 0
> .mask 0xd0000000,-8
> .fmask 0x00000000,0
> daddiu $sp,$sp,-64
> sd $31,56($sp)
> sd $fp,48($sp)
> sd $28,40($sp)
> move $fp,$sp
> lui $28,%hi(%neg(%gp_rel(RTLinker__ExpandModuleTable)))
> daddu $28,$28,$25
> daddiu $28,$28,%lo(%neg(%gp_rel(RTLinker__ExpandModuleTable)))
> .LBB9:
> .stabn 68,0,208,.LM109
> .LM109:
> sd $0,16($fp)
> .stabn 68,0,210,.LM110
> .LM110:
> dla $2,MM_RTLinker
> ld $2,0($2)      << WRONG
> bne $2,$0,.L61
> .stabn 68,0,212,.LM111
> .LM111:
> dla $3,MM_RTLinker
> ld $2,128($3)
> andi $2,$2,0x0
> ori $2,$2,0x1f4
> sd $2,128($3)
> .stabn 68,0,213,.LM112
> .LM112:
> li $4,4000   # 0xfa0
> jal malloc
> sd $2,0($fp)
> ld $4,0($fp)
> dla $3,MM_RTLinker
> ld $2,136($3)
> andi $2,$2,0x0
> or $2,$4,$2
> sd $2,136($3)     << OK, offset seems low, but it agrees with  
> elsewhere
> .stabn 68,0,214,.LM113
> .LM113:
> dla $2,MM_RTLinker
> ld $2,0($2)       << WRONG
> bne $2,$0,.L65
> jal abort
> b .L65
> .L61:
> .stabn 68,0,216,.LM114
> .LM114:
> dla $2,MM_RTLinker
> ld $2,0($2)        << WRONG
> dsll $2,$2,3
> sd $2,8($fp)
> .stabn 68,0,217,.LM115
> .LM115:
> ld $3,8($fp)
> ld $2,8($fp)
> daddu $2,$3,$2
> move $4,$2
> jal malloc
> sd $2,0($fp)
> ld $2,0($fp)
> sd $2,16($fp)
> .stabn 68,0,218,.LM116
> .LM116:
> ld $2,16($fp)
> bne $2,$0,.L64
> jal abort
> .L64:
> .stabn 68,0,219,.LM117
> .LM117:
> ld $4,16($fp)
> dla $2,MM_RTLinker
> ld $2,0($2)          << WRONG
> ld $3,8($fp)
> move $5,$2
> move $6,$3
> jal memcpy
> sd $2,0($fp)
> .stabn 68,0,220,.LM118
> .LM118:
> dla $2,MM_RTLinker
> ld $2,0($2)           << WRONG
> move $4,$2
> jal free
> .stabn 68,0,221,.LM119
> .LM119:
> ld $4,16($fp)
> dla $3,MM_RTLinker
> ld $2,136($3)         << OK
> andi $2,$2,0x0
> or $2,$4,$2
> sd $2,136($3)         << OK
> .stabn 68,0,222,.LM120
> .LM120:
> dla $2,MM_RTLinker
> ld $3,0($2)           << WRONG
> dla $2,MM_RTLinker
> ld $2,0($2)           << WRONG
> daddu $4,$3,$2
> dla $3,MM_RTLinker
> ld $2,128($3)         << OK
> andi $2,$2,0x0
> or $2,$2,$4
> sd $2,128($3)         << OK
> .L65:
> .LBE9:
> .stabn 68,0,224,.LM121
> .LM121:
> move $sp,$fp
> ld $31,56($sp)
> ld $fp,48($sp)
> ld $28,40($sp)
> daddiu $sp,$sp,64
> j $31
> .end RTLinker__ExpandModuleTable
>
> Here is corrected code:
>
> RTLinker__ExpandModuleTable:
> .frame $fp,64,$31  # vars= 32, regs= 3/0, args= 0, gp= 0
> .mask 0xd0000000,-8
> .fmask 0x00000000,0
> daddiu $sp,$sp,-64
> sd $31,56($sp)
> sd $fp,48($sp)
> sd $28,40($sp)
> move $fp,$sp
> lui $28,%hi(%neg(%gp_rel(RTLinker__ExpandModuleTable)))
> daddu $28,$28,$25
> daddiu $28,$28,%lo(%neg(%gp_rel(RTLinker__ExpandModuleTable)))
> .LBB9:
> .stabn 68,0,208,.LM109
> .LM109:
> sd $0,16($fp)
> .stabn 68,0,210,.LM110
> .LM110:
> dla $2,MM_RTLinker
> daddiu $2,$2,136     << CORRECT (offset seems low, but at least it  
> isn't zero)
> ld $2,0($2)
> bne $2,$0,.L61
> .stabn 68,0,212,.LM111
> .LM111:
> dla $2,MM_RTLinker
> daddiu $3,$2,128     << CORRECT
> li $2,500   # 0x1f4
> sd $2,0($3)
> .stabn 68,0,213,.LM112
> .LM112:
> li $4,4000   # 0xfa0
> jal malloc
> sd $2,0($fp)
> dla $2,MM_RTLinker
> daddiu $3,$2,136      << CORRECT
> ld $2,0($fp)
> sd $2,0($3)
> .stabn 68,0,214,.LM113
> .LM113:
> dla $2,MM_RTLinker
> daddiu $2,$2,136      << CORRECT
> ld $2,0($2)
> bne $2,$0,.L65
> jal abort
> b .L65
> .L61:
>
> I still dump core with this change, but I get much further.
> I have not tested this change at all otherwise -- i.e. on working  
> platforms.
>
> I have not debugged through the gcc/m3cg code to see why
> the offsets are only sometimes lost, or why other platforms
> have no problem. Is MIPS's "global pointer" unusual these days?
> I know SPARC has similar, and all the non-x86, non-AMD64 NT platforms
> had similar, but that's essentially nothing now (I'm not counting  
> IA64).
> I know Linux has PLT (procedure linkage table) and GOT (global  
> offset table).
> Same thing?
> I haven't looked much at other MIPS ports yet.
>
> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c.diff?r1=1.7;r2=1.8
>
> is what made it look about like it does -- in particularing using  
> BIT_FIELD_REF.
>
> 1.7:
>
> static void m3_load (v, o, src_t, src_T, dest_t, dest_T) /* GCC32OK */
>     tree v;
>     int o;
>     tree src_t, dest_t;
>     m3_type src_T, dest_T;
> {
>  if (o == 0 && TREE_TYPE (v) == src_t) {
>    EXPR_PUSH (v);
>  } else {
>    tree adr = m3_build1 (ADDR_EXPR, t_addr, v);
>    if (o != 0) {
>      adr = m3_build2 (PLUS_EXPR, t_addr, adr, size_int (o /  
> BITS_PER_UNIT));
>    }
>    EXPR_PUSH (m3_build1 (INDIRECT_REF, src_t,
>                          m3_cast (build_pointer_type (src_t), adr)));
>  }
> #if 1
>  if (src_T != dest_T) {
>    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, dest_t, EXPR_REF (-1));
>  }
>  if (debug_vars) {
>    const char *name = "noname";
>    if (v != 0 && DECL_NAME(v) != 0) {
>      name = IDENTIFIER_POINTER(DECL_NAME(v));
>    }
>    fprintf(stderr, "  m3_load (%s): offset %d, convert %d -> %d\n",  
> name,
>            o, src_T, dest_T);
>  }
> #else
>  if (src_T != dest_T) {
>    if (IS_INTEGER_TYPE(dest_T) && dest_t != t_int) {
>      EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t_int, EXPR_REF (-1));
>    } else if (IS_WORD_TYPE(dest_T) && dest_t != t_word) {
>      EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t_word, EXPR_REF (-1));
>    } else if (IS_INTEGER_TYPE(dest_T) || IS_WORD_TYPE(dest_T)) {
>      /* okay */
>    } else {
>      fatal_error("m3load: cannot convert types: src_t %d dest_t %d\n",
>                  src_T, dest_T);
>    }
>  }
> #endif
> }
> static void
> m3_store (v, o, src_t, dest_t)  /* GCC32OK */
>     tree v;
>     int o;
>     tree src_t, dest_t;
> {
>  tree lhs, rhs;
>  if (TREE_TYPE (EXPR_REF (-1)) == src_t) {
>    rhs = EXPR_REF (-1);
>  } else {
>    rhs = m3_cast (src_t, EXPR_REF (-1));
>  }
>  if (o == 0 && TREE_TYPE (v) == dest_t) {
>    lhs = v;
>  } else {
>    tree f = make_node (FIELD_DECL);
>    TREE_TYPE (f) = dest_t;
>    DECL_ALIGN (f) = TYPE_ALIGN (dest_t);
>    DECL_SIZE (f) = TYPE_SIZE (dest_t);
>    DECL_MODE (f) = TYPE_MODE (dest_t);
>    DECL_FIELD_OFFSET (f) = size_int (o / BITS_PER_UNIT);
>    DECL_FIELD_BIT_OFFSET (f) = bitsize_int (o % BITS_PER_UNIT);
>    DECL_FIELD_CONTEXT (f) = TREE_TYPE (v);
>    lhs = m3_build2 (COMPONENT_REF, dest_t, v, f);
>  }
> #if 1
>    expand_assignment (lhs, m3_build1 (CONVERT_EXPR, dest_t, rhs), 0,  
> 0);
> #else
>  if (dest_t ==  NULL) {
>    expand_assignment (lhs, rhs, 0, 0);
>  } else {
>    expand_assignment (lhs, m3_build1 (CONVERT_EXPR, dest_t, rhs), 0,  
> 0);
>  }
> #endif
>  EXPR_POP ();
> }
>
> 1.8:
> static void
> m3_load (tree v, int o,
>  tree src_t, m3_type src_T,
>  tree dst_t, m3_type dst_T) /* GCC32OK */
> {
>  if (o == 0 && TREE_TYPE (v) == src_t) {
>    EXPR_PUSH (v);
>  } else {
>    EXPR_PUSH (m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>     bitsize_int (o)));
>  }
>  if (src_T != dst_T) {
>    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, dst_t, EXPR_REF (-1));
>  }
>  if (option_vars_trace) {
>    const char *name = "noname";
>    if (v != 0 && DECL_NAME(v) != 0) {
>      name = IDENTIFIER_POINTER(DECL_NAME(v));
>    }
>    fprintf(stderr, "  m3_load (%s): offset %d, convert %d -> %d\n",  
> name,
>     o, src_T, dst_T);
>  }
> }
> static void
> m3_store (tree v, int o, tree src_t, tree dst_t)  /* GCC32OK */
> {
>  tree lhs, rhs;
>  if (TREE_TYPE (EXPR_REF (-1)) == src_t) {
>    rhs = EXPR_REF (-1);
>  } else {
>    rhs = m3_cast (src_t, EXPR_REF (-1));
>  }
>  if (o == 0 && TREE_TYPE (v) == dst_t) {
>    lhs = v;
>  } else {
>    lhs = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>       bitsize_int (o));
>  }
>  if (src_t != dst_t) {
>    rhs = m3_build1 (CONVERT_EXPR, dst_t, rhs);
>  }
>  expand_assignment (lhs, rhs, 0, 0);
>  EXPR_POP ();
> }
>
> - Jay
>
> <AMD64_LINUX_RTLinker.mc><MIPS64_OPENBSD_RTLinker.mc>
>
>
>
>

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


More information about the M3devel mailing list