<html><head><base href="x-msg://438/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations).<div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div><font class="Apple-style-span" color="#0000FF"><font class="Apple-style-span" face="Gill Sans"><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; "><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; ">Antony Hosking</span></span></font></font><font class="Apple-style-span" face="Gill Sans"><span class="Apple-style-span" style="font-family: 'Gill Sans'; "><span class="Apple-style-span" style="font-family: 'Gill Sans'; "><span class="Apple-converted-space"> </span>|<span class="Apple-converted-space"> </span></span></span><span class="Apple-style-span" style="font-family: 'Gill Sans'; "><span class="Apple-style-span" style="font-family: 'Gill Sans'; ">Associate Professor</span></span><span class="Apple-style-span" style="font-family: 'Gill Sans'; "><span class="Apple-style-span" style="font-family: 'Gill Sans'; "> | Computer Science | Purdue University</span></span></font></div><div><font class="Apple-style-span" face="GillSans-Light"><span class="Apple-style-span" style="font-family: GillSans-Light; ">305 N. University Street | West Lafayette | IN 47907 | USA</span></font></div><div><font class="Apple-style-span" color="#0000FF" face="Gill Sans"><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; "><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; ">Office</span></span></font><font class="Apple-style-span" face="GillSans-Light"><span class="Apple-style-span" style="font-family: GillSans-Light; "><span class="Apple-style-span" style="font-family: GillSans-Light; "> +1 765 494 6001 |<span class="Apple-converted-space"> </span></span></span></font><font class="Apple-style-span" color="#0000FF" face="Gill Sans"><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; "><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font class="Apple-style-span" face="GillSans-Light"><span class="Apple-style-span" style="font-family: GillSans-Light; "><span class="Apple-style-span" style="font-family: GillSans-Light; "><span class="Apple-converted-space"> </span>+1 765 427 5484</span></span></font></div><div><font class="Apple-style-span" face="GillSans-Light"><br class="khtml-block-placeholder"></font></div></span></span></span></span></span></span></span><br class="Apple-interchange-newline"></span></div></span></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On 27 Feb 2010, at 14:11, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter.<br> We probably don't generate atomic operations against them.<br> I already changed it to 64 for the front/middle ends<br> <br>But right, max_align is wrong for a few targets.<br> <br>I believe max_align ends up being basically target-independent. It is always 64.<br> Types are always aligned on their size.<br>The only exceptions are 68K platforms where max_align is possibly 2 bytes.<br> 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list.<br> <br> <br>PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs<br>that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems<br>like a language hole to me.<br> <br> <br>I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86.<br> <br> <br> - Jay<br><br> <br>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Sat, 27 Feb 2010 11:10:32 -0500<br>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] TInt/TWord/N<br>><span class="Apple-converted-space"> </span><br>> Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though.<br>> On 27 Feb 2010, at 02:34, Jay K wrote:<br>><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> >> As I understand it your stuff in m3back is mostly working.<br>> >> I took a look at the code there and I see a number of issues<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > Tony, I don't know of anything that isn't working.<br>> > Please let me know.<br>> > All 64bit operations should work. atomic32 should work.<br>> > Not yet atomic8/16/64, soon.<br>> > Oh there is an alignment issue once atomic64 is there.<br>> > It's present on other platforms too, for different reasons (incorrect max_align).<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > Thanks,<br>> > - Jay<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > ----------------------------------------<br>> >> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> Date: Sat, 27 Feb 2010 01:16:32 -0500<br>> >> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >> Subject: Re: [M3devel] TInt/TWord/N<br>> >><span class="Apple-converted-space"> </span><br>> >> The solution is not to push upstream into m3middle.<br>> >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime.<br>> >><span class="Apple-converted-space"> </span><br>> >> -- T<br>> >><span class="Apple-converted-space"> </span><br>> >> On 26 Feb 2010, at 23:48, Jay K wrote:<br>> >><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> Tony, I just don't understand what is wrong with TIntN, TWordN.<br>> >>> They are what TInt/TWord did for a long time after all. ?<br>> >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks.<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> - Jay<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> ----------------------------------------<br>> >>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500<br>> >>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jkrell@elego.de">jkrell@elego.de</a><br>> >>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this.<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote:<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>>> CVSROOT: /usr/cvs<br>> >>>>> Changes by: jkrell@birch. 10/02/26 13:48:34<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> Modified files:<br>> >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3<br>> >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3<br>> >>>>> Wrx86.i3 Wrx86.m3 m3makefile<br>> >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3<br>> >>>>> TWordN.i3 TWordN.m3 Target.i3<br>> >>>>> Target.m3 m3makefile<br>> >>>>> Removed files:<br>> >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3<br>> >>>>> M3BackWord.m3<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> Log message:<br>> >>>>> introduce type Target.IntN which is Int plus a precision<br>> >>>>> just like the old Target.Int<br>> >>>>> (previously M3BackInt.Int)<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> make TIntN and TWordN support it<br>> >>>>> they are just thin wrappers over TInt, TWord<br>> >>>>> previously named M3BackInt, M3BackWord<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> add small amount of support to TInt:<br>> >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate<br>> >>>>> These could, if desired, go into their only users: TIntN, TWordN.<br>> >>>>> (with the understanding that that Target.Int is "revealed" to them.)<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged<br>> >>>>> This is "just" additions.<br>> >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.)<br>> >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN)<br>> >>>>> (A little unsatisfactory that N is bytes instead of bits.)<br>> >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) )<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> While at it, in TIntN, rename things slightly:<br>> >>>>> FromInt => FromHostInteger<br>> >>>>> ToInt => ToHostInteger<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> "Int" is "Target.Int"<br>> >>>>> "HostInteger" is "INTEGER"<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> again, TInt/TWord/m3front/m3middle not much affected.<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds<br>> >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we<br>> >>>>> really need INTEGER to be 4 bytes throughout m3back?<br>> >>>>> (I know that mklib has little endian dependency.)<br>> >>>><span class="Apple-converted-space"> </span><br>> >><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br></div></span></blockquote></div><br></div></body></html>