[M3devel] what does it mean to read a UINT8?

[Jay K]

C addresses some of this very simply and thoroughly:
 1) layout of bitfields is implementation independent
 2) I think even the ability to declare some bitfields is not guaranteeed,
  e.g. int a : 33
 3) You can't take the address of bitfields. This is the key one I think.
 4) Bitfields can only occur in structs/unions, not in typedefs,
 variables, parameters, return types, etc.

 - Jay



 
From: jay.krell at cornell.edu
To: rodney_bates at lcwb.coop; m3devel at elegosoft.com
Date: Sun, 22 Sep 2013 17:47:07 +0000
Subject: Re: [M3devel] what does it mean to read a UINT8?




UINT8 is [0..255] I think.
I tried "BITS 8 FOR" on it at some point but such things on that family of types (UINT16, UINT32, UINT64) caused compilation errors. (These are all via Ctypes.i3)

The pointer before subtraction is 64K-aligned.

I don't think the other types should matter.

I still have to compare with integrated backend or cm3cg.
 
 - Jay

> Date: Sun, 22 Sep 2013 12:17:18 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] what does it mean to read a UINT8?
> 
> As in my other response, I think you are left entirely too much
> out in the wind by the language/compiler as to what your expectations
> should be. In this particular example, it would help to know the type
> UINT8, and those of 'used', 'info', 'RegionSize', and maybe 'b'.  I
> could make some guesses, but that could turn out a snipe hunt.
> 
> Do you mean it copies a full INTEGER into b, or just fetches
> an INTEGER, then extracts from it?  What is the alignment of
> the actual address in the failing case?
> 
> On 09/21/2013 10:58 PM, Jay K wrote:
> > It appears that this code:
> >
> >
> > b := LOOPHOLE(used + info.RegionSize - 1, UNTRACED REF UINT8)^;
> >
> >
> > generates a read of a full INTEGER, in this case 8 bytes.
> >
> >
> > Now, I know, I could change it to:
> >
> >
> > b := LOOPHOLE(used + info.RegionSize - BYTESIZE(INTEGER), UNTRACED REF INTEGER)^;
> >
> >
> > What were my expectations wrong in the first place?
> >
> >
> > This code was part of getting stack bounds and it'd read
> > the end of the stack to try to ensure it was correct.
> >
> >
> > I removed it.
> >
> >
> > 0:000> g
> > (15bc.116c): Access violation - code c0000005 (first chance)
> > First chance exceptions are reported before any exception handling.
> > This exception may be expected and handled.
> > *** WARNING: Unable to verify checksum for cm3.exe
> > cm3!ThreadWin32__GetStackBounds+0x1e8:
> > 00000001`3fdf1a78 488b48ff        mov     rcx,qword ptr [rax-1] ds:00000000`0028
> > ffff=????????????????
> > 0:000> r rax
> > rax=0000000000290000
> > 0:000> r rsp
> > rsp=000000000028fb60
> > 0:000> dv
> >      start_L_275 = 0x00000000`00338de0
> >        end_L_276 = 0x00000000`00338de8
> >      L_501_L_502 = 0n48
> >       used_L_272 = 0x00000000`0028f000
> > available_L_273 = 0x00000000`00190000 "--- memory read error at address 0x000000
> > 00`00190000 ---"
> >          b_L_274 = 0x30 '0'
> >          a_L_271 = 0n48
> >       info_L_270 = struct TA669C7A1
> >           _frame = struct ThreadWin32__GetStackBounds_Frame_t
> > 0:000> ?? info_L_270
> > struct TA669C7A1
> >     +0x000 BaseAddress      : 0x00000000`0028f000  "0???"
> >     +0x008 AllocationBase   : 0x00000000`00190000  "--- memory read error at addr
> > ess 0x00000000`00190000 ---"
> >     +0x010 AllocationProtect : 4
> >     +0x014 L_7              : [4]  ""
> >     +0x018 RegionSize       : 0n4096
> >     +0x020 State            : 0x1000
> >     +0x024 Protect          : 4
> >     +0x028 Type             : 0x20000
> >     +0x02c L_8              : [4]  ""
> > 0:000> q
> > quit:
> >
> >
> >   - Jay
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130923/2e075345/attachment-0002.html>