<html><head><base href="x-msg://1999/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ah, yes, I see. You're right.<div>The same proc is stored multiple times.</div><div>We could indeed simply have a variable initialized once with the value of the proc.</div><div><br>
<br><div><div>On Jan 6, 2011, at 11:08 PM, 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-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; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">I don't think so, but maybe.<br><br>For i := 1 to 10 do try finally end<br><br>will run that generated code 10 times but only the 1st is needed. In general? I not sure.<br><br>Jay/phone<br><br>> Subject: Re: [M3commit] CVS Update: cm3<br>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Thu, 6 Jan 2011 16:56:48 -0500<br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>><span class="Apple-converted-space"> </span><br>> You are confusing code emitted in the body of the loop with dynamic executions of that code.<br>> CG calls are all compile-time generation of code.<br>><span class="Apple-converted-space"> </span><br>> On Jan 6, 2011, at 4:17 PM, Jay K wrote:<br>><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > If I have a try/finally or lock in a loop, those lines aren't going to guaranteeably store the same values each time?<br>> ><span class="Apple-converted-space"> </span><br>> > - Jay<br>> ><span class="Apple-converted-space"> </span><br>> > ----------------------------------------<br>> >> Subject: Re: [M3commit] CVS Update: cm3<br>> >> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> Date: Thu, 6 Jan 2011 16:00:08 -0500<br>> >> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >><span class="Apple-converted-space"> </span><br>> >> In the code below there are no initializations.<br>> >><span class="Apple-converted-space"> </span><br>> >> On Jan 6, 2011, at 3:51 PM, Jay K wrote:<br>> >><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> ps: I think there other non-ideal initializations here.<br>> >>> e.g.<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> TryFinStmt.m3:Compile2<br>> >>> (* declare and initialize the info record *)<br>> >>> frame := CG.Declare_local (M3ID.NoID, M3RT.EF2_SIZE, Target.Address.align,<br>> >>> CG.Type.Struct, 0, in_memory := TRUE,<br>> >>> up_level := FALSE, f := CG.Never);<br>> >>> CG.Load_procedure (p.handler.cg_proc);<br>> >>> CG.Store_addr (frame, M3RT.EF2_handler);<br>> >>> CG.Load_static_link (p.handler.cg_proc);<br>> >>> CG.Store_addr (frame, M3RT.EF2_frame);<br>> >>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><br>> >>> Putting TRY/LOCK in loops probably repeatedly does the same initializations.<br>> >>> Granted, this is non-stack-walker code.<br>> >>><span class="Apple-converted-space"> </span><br>> >>> Seems all bit a suspicious to me, though I'm pretty ignorant of m3front still..<br>> >>><span class="Apple-converted-space"> </span><br>> >>> - Jay<br>> >>><span class="Apple-converted-space"> </span><br>> >>> ----------------------------------------<br>> >>>> From:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>> To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</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>> >>>> Date: Thu, 6 Jan 2011 20:48:56 +0000<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> The same way as before. I think this operates at too low a level to get any automatic initialization.<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> TryStmt.m3 and TryFinStmt.m3:<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> frame := CG.Declare_local (M3ID.NoID, M3RT.EF1_SIZE, Target.Address.align,<br>> >>>> CG.Type.Struct, 0, in_memory := TRUE,<br>> >>>> up_level := FALSE, f := CG.Never);<br>> >>>><span class="Apple-converted-space"> </span><br>> >>>> I agree though, this might not be ideal.<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>> >>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>> Date: Thu, 6 Jan 2011 15:42:33 -0500<br>> >>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> I don't understand what you mean by "initializes to NIL".<br>> >>>>> How are you creating the frame variable?<br>> >>>>> If you do it properly the language semantics will cause it be initialized to NIL automatically.<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>> On Jan 6, 2011, at 3:33 PM, Jay K wrote:<br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> Ok.<br>> >>>>>> Do you know where to initialize the jmpbuf to NIL?<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> I have a diff that "works" (ie: doesn't crash) and is *close* to correct,<br>> >>>>>> it checks for NIL and branches around the alloca for non-NIL, but it<br>> >>>>>> also initializes to NIL repeatedly, so no change effectively.<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> Index: misc/Marker.m3<br>> >>>>>> ===================================================================<br>> >>>>>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/misc/Marker.m3,v<br>> >>>>>> retrieving revision 1.7<br>> >>>>>> diff -u -w -r1.7 Marker.m3<br>> >>>>>> --- misc/Marker.m3 5 Jan 2011 14:34:54 -0000 1.7<br>> >>>>>> +++ misc/Marker.m3 6 Jan 2011 20:32:00 -0000<br>> >>>>>> @@ -233,6 +233,7 @@<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> PROCEDURE CaptureState (frame: CG.Var; handler: CG.Label) =<br>> >>>>>> VAR new: BOOLEAN;<br>> >>>>>> + label := CG.Next_label ();<br>> >>>>>> BEGIN<br>> >>>>>> (* int setjmp(void* ); *)<br>> >>>>>> IF (setjmp = NIL) THEN<br>> >>>>>> @@ -263,18 +264,25 @@<br>> >>>>>> Target.Word.cg_type, 0);<br>> >>>>>> END;<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> + (* IF frame.jmpbuf = NIL THEN *)<br>> >>>>>> +<br>> >>>>>> + CG.Load_nil ();<br>> >>>>>> + CG.Load_addr (frame, M3RT.EF1_jmpbuf);<br>> >>>>>> + CG.If_compare (Target.Address.cg_type, CG.Cmp.NE, label, CG.Maybe);<br>> >>>>>> +<br>> >>>>>> (* frame.jmpbuf = alloca(Csetjmp__Jumpbuf_size); *)<br>> >>>>>> CG.Start_call_direct (alloca, 0, Target.Address.cg_type);<br>> >>>>>> CG.Load_int (Target.Word.cg_type, Jumpbuf_size);<br>> >>>>>> CG.Pop_param (Target.Word.cg_type);<br>> >>>>>> CG.Call_direct (alloca, Target.Address.cg_type);<br>> >>>>>> - CG.Store (frame, M3RT.EF1_jmpbuf, Target.Address.size, Target.Address.align,<br>> >>>>>> - Target.Address.cg_type);<br>> >>>>>> + CG.Store_addr (frame, M3RT.EF1_jmpbuf);<br>> >>>>>> +<br>> >>>>>> + (* END *)<br>> >>>>>> + CG.Set_label (label);<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> (* setmp(frame.jmpbuf) *)<br>> >>>>>> CG.Start_call_direct (setjmp, 0, Target.Integer.cg_type);<br>> >>>>>> - CG.Load (frame, M3RT.EF1_jmpbuf, Target.Address.size, Target.Address.align,<br>> >>>>>> - Target.Address.cg_type);<br>> >>>>>> + CG.Load_addr (frame, M3RT.EF1_jmpbuf);<br>> >>>>>> CG.Pop_param (CG.Type.Addr);<br>> >>>>>> CG.Call_direct (setjmp, Target.Integer.cg_type);<br>> >>>>>> CG.If_true (handler, CG.Never);<br>> >>>>>> cvs diff: Diffing stmts<br>> >>>>>> Index: stmts/TryFinStmt.m3<br>> >>>>>> ===================================================================<br>> >>>>>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/stmts/TryFinStmt.m3,v<br>> >>>>>> retrieving revision 1.6<br>> >>>>>> diff -u -w -r1.6 TryFinStmt.m3<br>> >>>>>> --- stmts/TryFinStmt.m3 5 Jan 2011 14:34:54 -0000 1.6<br>> >>>>>> +++ stmts/TryFinStmt.m3 6 Jan 2011 20:32:00 -0000<br>> >>>>>> @@ -299,6 +299,10 @@<br>> >>>>>> CG.Load_nil ();<br>> >>>>>> CG.Store_addr (frame, M3RT.EF1_info + M3RT.EA_exception);<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> + (* no jmpbuf yet (avoid repeated alloca in try within loop) *)<br>> >>>>>> + CG.Load_nil ();<br>> >>>>>> + CG.Store_addr (frame, M3RT.EF1_jmpbuf);<br>> >>>>>> +<br>> >>>>>> l := CG.Next_label (3);<br>> >>>>>> CG.Set_label (l, barrier := TRUE);<br>> >>>>>> Marker.PushFrame (frame, M3RT.HandlerClass.Finally);<br>> >>>>>> Index: stmts/TryStmt.m3<br>> >>>>>> ===================================================================<br>> >>>>>> RCS file: /usr/cvs/cm3/m3-sys/m3front/src/stmts/TryStmt.m3,v<br>> >>>>>> retrieving revision 1.3<br>> >>>>>> diff -u -w -r1.3 TryStmt.m3<br>> >>>>>> --- stmts/TryStmt.m3 5 Jan 2011 14:34:54 -0000 1.3<br>> >>>>>> +++ stmts/TryStmt.m3 6 Jan 2011 20:32:00 -0000<br>> >>>>>> @@ -10,7 +10,7 @@<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> IMPORT M3, M3ID, CG, Variable, Scope, Exceptionz, Value, Error, Marker;<br>> >>>>>> IMPORT Type, Stmt, StmtRep, TryFinStmt, Token;<br>> >>>>>> -IMPORT Scanner, ESet, Target, M3RT, Tracer;<br>> >>>>>> +IMPORT Scanner, ESet, Target, M3RT, Tracer, IO;<br>> >>>>>> FROM Scanner IMPORT Match, MatchID, GetToken, Fail, cur;<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> TYPE<br>> >>>>>> @@ -411,6 +411,10 @@<br>> >>>>>> CG.Store_addr (frame, M3RT.EF1_exception);<br>> >>>>>> ***********************************************)<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> + (* no jmpbuf yet (avoid repeated alloca in try within loop) *)<br>> >>>>>> + CG.Load_nil ();<br>> >>>>>> + CG.Store_addr (frame, M3RT.EF1_jmpbuf);<br>> >>>>>> +<br>> >>>>>> IF (p.hasElse) THEN<br>> >>>>>> Marker.PushTryElse (l, l+1, frame);<br>> >>>>>> Marker.PushFrame (frame, M3RT.HandlerClass.ExceptElse);<br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>>> The set_label before one of the PushEFrames could be moved down a bit,<br>> >>>>>> to after the NIL initialization, and that'd fix some cases, but I think not all.<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>> >>>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>> Date: Thu, 6 Jan 2011 14:11:04 -0500<br>> >>>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>> At this point, we are trying to move away from the setjmp implementation to one that relies on unwind support, so I don't think the effort here is worthwhile.<br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>> Antony Hosking | Associate Professor | Computer Science | Purdue University<br>> >>>>>>> 305 N. University Street | West Lafayette | IN 47907 | USA<br>> >>>>>>> Office +1 765 494 6001 | Mobile +1 765 427 5484<br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>> On Jan 6, 2011, at 2:00 PM, Jay K wrote:<br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> I believe you can, but it'd take significant work in the frontend.<br>> >>>>>>>> The jmpbuf should identify merely which procedure/frame to return to.<br>> >>>>>>>> There would also be a volatile local integer, that gets altered at certain points through the function.<br>> >>>>>>>> When setjmp returns exceptionally, you'd switch on that integer to determine where to "really" go.<br>> >>>>>>>> This is analogous to how other systems work -- NT/x86 has a highly optimized frame based exception<br>> >>>>>>>> handling. Instead of a generic thread local, FS:0 is reserved to be the head of the linked list of frames.<br>> >>>>>>>> Instead of setjmp, the compiler pessimizes appropriately.<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> So the result is that a function with one or more tries, or one or more locals with destructors,<br>> >>>>>>>> puts one node on the FS:0 list, and then mucks with the volatile local integer to indicate<br>> >>>>>>>> where in the function it is.<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> If NT/x86 were inefficient more analogous to current Modula-3, it'd link/unlink in FS:0 more often.<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> It is more work through, granted, I can understand that.<br>> >>>>>>>> And given that we have a much better option for many platforms, the payoff would be reduced.<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> Anyway, I'm trying what you say, like for TRY within a loop.<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> I should point out that alloca has an extra inefficiency vs. the previous approach.<br>> >>>>>>>> It aligns more. So it is using more stack than the other way.<br>> >>>>>>>> And it might pessimize codegen in other ways.<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> The gcc code appears somewhat similar..I think the tables merely describe, again, which<br>> >>>>>>>> function/frame to return to, and that within the frame there is a local integer to determine<br>> >>>>>>>> more precisely what to do. I'm not sure. I saw mention of a switch.<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> - Jay<br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>> ________________________________<br>> >>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>>>> Date: Thu, 6 Jan 2011 13:52:42 -0500<br>> >>>>>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> You can't have one jmpbuf per procedure. You need one per TRY scope,<br>> >>>>>>>>> since they can be nested.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> On Jan 6, 2011, at 11:35 AM, Jay K wrote:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Hm. How do I single instance the "EF1"? The current code allocates a<br>> >>>>>>>>> local "EF1" for each try.<br>> >>>>>>>>> I guess, really, it is EF1, EF2, etc.<br>> >>>>>>>>> So there should be a separate local for the jmpbuf pointer, and store<br>> >>>>>>>>> it in each EF* block?<br>> >>>>>>>>> How do I make just one jmpbuf pointer? I couldn't easily figure out how<br>> >>>>>>>>> to in the front end, I need to read it more.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> something like:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> PROCEDURE F1() = BEGIN TRY1 do stuff1 TRY2 do stuff 2 TRY3 do stuff 3<br>> >>>>>>>>> END END END END F1;<br>> >>>>>>>>> =><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> void F1()<br>> >>>>>>>>> {<br>> >>>>>>>>> jmp_buf* jb = 0;<br>> >>>>>>>>> EF1 a,b,c;<br>> >>>>>>>>> setjmp(a.jmpbuf = jb ? jb : (jb = alloca(sizeof(jmp_buf))); // TRY1<br>> >>>>>>>>> do stuff 1...<br>> >>>>>>>>> setjmp(b.jmpbuf = jb ? jb : (jb = alloca(sizeof(jmp_buf))); // TRY2<br>> >>>>>>>>> do stuff 2...<br>> >>>>>>>>> setjmp(c.jmpbuf = jb ? jb : (jb = alloca(sizeof(jmp_buf))); // TRY3<br>> >>>>>>>>> do stuff 3...<br>> >>>>>>>>> }<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> (The actual syntactic and semantic correctness of this code -- the<br>> >>>>>>>>> existance of the ternary operator, and that it only evaluates one side<br>> >>>>>>>>> or the other, and that assignment is expression..I quite like those<br>> >>>>>>>>> features....)<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Still, something I can't pin down strikes me as too simple here.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> If there is just one setjmp, and no integer(s) to keep track of<br>> >>>>>>>>> additional progress, you only ever know the last place you were in a<br>> >>>>>>>>> function.<br>> >>>>>>>>> That doesn't seem adequate.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> What if a function raises an exception, catches it within itself, and<br>> >>>>>>>>> then raises something else, and then wants to catch that?<br>> >>>>>>>>> It won't know where to resume, right? It's just keep longjmping to the<br>> >>>>>>>>> same place.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> In the Visual C++ runtime, there is "local unwind" and "global unwind".<br>> >>>>>>>>> "local unwind" is like, "within the same functin", "global unwind" is<br>> >>>>>>>>> across functions.<br>> >>>>>>>>> I think somehow that is related here.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> e.g. how would you ensure forward progress in this:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> EXCEPTION E1;<br>> >>>>>>>>> EXCEPTION E2;<br>> >>>>>>>>> EXCEPTION E3;<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> PROCEDURE F4() RAISES ANY =<br>> >>>>>>>>> CONST Function = "F4 ";<br>> >>>>>>>>> BEGIN<br>> >>>>>>>>> Put(Function & Int(Line())); NL();<br>> >>>>>>>>> TRY<br>> >>>>>>>>> Put(Function & Int(Line())); NL();<br>> >>>>>>>>> TRY<br>> >>>>>>>>> Put(Function & Int(Line())); NL();<br>> >>>>>>>>> TRY<br>> >>>>>>>>> Put(Function & Int(Line())); NL();<br>> >>>>>>>>> RAISE E1;<br>> >>>>>>>>> EXCEPT ELSE<br>> >>>>>>>>> RAISE E2;<br>> >>>>>>>>> END;<br>> >>>>>>>>> EXCEPT ELSE<br>> >>>>>>>>> RAISE E3;<br>> >>>>>>>>> END;<br>> >>>>>>>>> EXCEPT ELSE<br>> >>>>>>>>> END;<br>> >>>>>>>>> END F4;<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Oddly in my test p251, the stack depth is not increased by TRY.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> - Jay<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> ________________________________<br>> >>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>>>> Date: Thu, 6 Jan 2011 09:22:09 -0500<br>> >>>>>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> I am OK with what you have currently:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> At each TRY:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> 1. Check if a corresponding alloca block has been allocated by checking<br>> >>>>>>>>> if the corresponding local variable is NIL.<br>> >>>>>>>>> 2. If not, then alloca and save its pointer in the local variable<br>> >>>>>>>>> 3. Execute the try block.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> As you say, alloca should turn into an inline operation using the<br>> >>>>>>>>> compiler's builtin implementation of alloca.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> On Jan 6, 2011, at 1:02 AM, Jay K wrote:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>>> Code size will suffer.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Indeed. Unoptimized code size does suffer a lot, in functions that use try.<br>> >>>>>>>>> Calling alloca, unoptimized, isn't small, and this adds n calls for n trys.<br>> >>>>>>>>> I thought it'd only be one call. I didn't realize our implementation<br>> >>>>>>>>> is as poor as it is, since a better but still<br>> >>>>>>>>> portable implementation doesn't seem too too difficult.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Can we maybe do the optimizations I indicate -- no more than one<br>> >>>>>>>>> setjmp/alloca/pushframe per function?<br>> >>>>>>>>> Using a local integer to record the position within the function?<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Or just give me a week or few to get stack walking working and then<br>> >>>>>>>>> live the regression on other targets?<br>> >>>>>>>>> (NT386 isn't likely to get stack walking, though it *is* certainly<br>> >>>>>>>>> possible; NT does have a decent runtime here..)<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> It *is* nice to not have have the frontend know about jmpbuf size.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> I looked into the "builtin_setjmp" stuff, but it can't be used so easily.<br>> >>>>>>>>> It doesn't work for intra-function jumps, only inter-function.<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:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</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>> >>>>>>>>> Date: Thu, 6 Jan 2011 04:52:33 +0000<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Ah..I'm doing more comparisons of release vs. head...but..I guess your<br>> >>>>>>>>> point is, you'd rather have n locals, which the backend automatically<br>> >>>>>>>>> merges, than n calls to alloca?<br>> >>>>>>>>> It's not a huge difference -- there are still going to be n calls to<br>> >>>>>>>>> setjmp and n calls to pthread_getspecific.<br>> >>>>>>>>> The alloca calls will be dwarfed.<br>> >>>>>>>>> Code size will suffer.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> And, even so, there are plenty of optimizations to be had, even if<br>> >>>>>>>>> setjmp/pthread_getspecific is used.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> - It could make a maximum of one call to setjmp/pthread_getspecific<br>> >>>>>>>>> per function<br>> >>>>>>>>> - The calls to alloca could be merged. The frontend could keep track<br>> >>>>>>>>> of how many calls it makes per function,<br>> >>>>>>>>> issue a multiplication, and offset each jmpbuf. It is a tradeoff.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> So, yes, given my current understanding, it is progress.<br>> >>>>>>>>> The target-dependence is not worth it, imho.<br>> >>>>>>>>> I'll still do some comparisons to release.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> I'll still be looking into using the gcc unwinder relatively soon.<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>> >>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>>>> Date: Wed, 5 Jan 2011 21:14:17 -0500<br>> >>>>>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> On Jan 5, 2011, at 9:08 PM, Jay K wrote:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Tony, um..well, um.. first, isn't that how it already worked maybe?<br>> >>>>>>>>> Declaring a new local EF1 for each TRY? It looks like it.<br>> >>>>>>>>> I'll do more testing.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Yes, it did. I assume you simply have a local variable for each TRY<br>> >>>>>>>>> block that is a pointer now instead of a jmp_buf. Should be OK.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> So the additional inefficiency is multiplied the same as the rest of<br>> >>>>>>>>> the preexisting inefficiency.<br>> >>>>>>>>> And the preexisting inefficiency is way more than the increase.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> And second, either way, it could be better.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Basically, the model should be, that if a function has any try or lock,<br>> >>>>>>>>> it calls setjmp once.<br>> >>>>>>>>> And then, it should have one volatile integer, that in a sense<br>> >>>>>>>>> represents the line number.<br>> >>>>>>>>> But not really. It's like, every time you cross a TRY, the integer is<br>> >>>>>>>>> incremented, every time you<br>> >>>>>>>>> cross a finally or unlock, the integer is decremented. Or rather, the<br>> >>>>>>>>> value can be stored.<br>> >>>>>>>>> And then there is a maximum of one one handler per function, it<br>> >>>>>>>>> switches on the integer<br>> >>>>>>>>> to decide where it got into the function and what it should do.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> This is how other compilers work and it is a fairly simple sensible approach.<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>> >>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>>>> Date: Wed, 5 Jan 2011 20:49:24 -0500<br>> >>>>>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Note that you need a different jmpbuf for each nested TRY!<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Antony Hosking | Associate Professor | Computer Science | Purdue University<br>> >>>>>>>>> 305 N. University Street | West Lafayette | IN 47907 | USA<br>> >>>>>>>>> Office +1 765 494 6001 | Mobile +1 765 427 5484<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> On Jan 5, 2011, at 8:33 PM, Jay K wrote:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> oops, that's not how I thought it worked. I'll do more testing and fix<br>> >>>>>>>>> it -- check for NIL.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> - Jay<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> ________________________________<br>> >>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>>>> Date: Wed, 5 Jan 2011 20:23:09 -0500<br>> >>>>>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Ah, yes, I guess you need a different jmpbuf for each TRY. But now you<br>> >>>>>>>>> are allocating on every TRY where previously the storage was statically<br>> >>>>>>>>> allocated. Do you really think this is progress?<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> On Jan 5, 2011, at 5:40 PM, Jay K wrote:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> I've back with full keyboard if more explanation needed. The diff is<br>> >>>>>>>>> actually fairly small to read.<br>> >>>>>>>>> I understand it is definitely less efficient, a few more instructions<br>> >>>>>>>>> for every try/lock.<br>> >>>>>>>>> No extra function call, at least with gcc backend.<br>> >>>>>>>>> I haven't tested NT386 yet. Odds are so/so that it works -- the change<br>> >>>>>>>>> is written so that it should work<br>> >>>>>>>>> but I have to test it to be sure, will to roughly tonight. And there<br>> >>>>>>>>> probably is a function call there.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> - Jay<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> ________________________________<br>> >>>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>>>> Date: Wed, 5 Jan 2011 20:44:08 +0000<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 only have phone right now. I think it is fairly clear: the jumpbuf in<br>> >>>>>>>>> EF1 is now allocated with alloca, and a pointer stored. It is<br>> >>>>>>>>> definitely a bit less efficient, but the significant advantage is<br>> >>>>>>>>> frontend no longer needs to know the size or alignment of a jumpbuf.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> As well, there is no longer the problem regarding jumpbuf aligned to<br>> >>>>>>>>> more than 64 bits. I at least checked on Linux/PowerPC and alloca seems<br>> >>>>>>>>> to align to 16 bytes. I don't have an HPUX machine currently to see if<br>> >>>>>>>>> the problem is addressed there.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> The inefficiency of course can be dramatically mitigated via a stack<br>> >>>>>>>>> walker. I wanted to do this first though, while more targets using<br>> >>>>>>>>> setjmp.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> - Jay/phone<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> ________________________________<br>> >>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3<br>> >>>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >>>>>>>>> Date: Wed, 5 Jan 2011 13:35:59 -0500<br>> >>>>>>>>> CC:<span class="Apple-converted-space"> </span><a href="mailto:jkrell@elego.de">jkrell@elego.de</a>;<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Can you provide a more descriptive checkin comment? I don't know what<br>> >>>>>>>>> has been done here without diving into the diff.<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> Antony Hosking | Associate Professor | Computer Science | Purdue University<br>> >>>>>>>>> 305 N. University Street | West Lafayette | IN 47907 | USA<br>> >>>>>>>>> Office +1 765 494 6001 | Mobile +1 765 427 5484<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> On Jan 5, 2011, at 9:37 AM, Jay K wrote:<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>> diff attached<br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>>> Date: Wed, 5 Jan 2011 15:34:55 +0000<br>> >>>>>>>>>> To:<span class="Apple-converted-space"> </span><a href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</a><br>> >>>>>>>>>> From:<span class="Apple-converted-space"> </span><a href="mailto:jkrell@elego.de">jkrell@elego.de</a><br>> >>>>>>>>>> Subject: [M3commit] CVS Update: cm3<br>> >>>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>>> CVSROOT: /usr/cvs<br>> >>>>>>>>>> Changes by: jkrell@birch. 11/01/05 15:34:55<br>> >>>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>>> Modified files:<br>> >>>>>>>>>> cm3/m3-libs/m3core/src/C/Common/: Csetjmp.i3<br>> >>>>>>>>>> cm3/m3-libs/m3core/src/C/I386_CYGWIN/: Csetjmp.i3<br>> >>>>>>>>>> cm3/m3-libs/m3core/src/C/I386_MINGW/: Csetjmp.i3<br>> >>>>>>>>>> cm3/m3-libs/m3core/src/C/I386_NT/: Csetjmp.i3<br>> >>>>>>>>>> cm3/m3-libs/m3core/src/C/NT386/: Csetjmp.i3<br>> >>>>>>>>>> cm3/m3-libs/m3core/src/runtime/ex_frame/: RTExFrame.m3<br>> >>>>>>>>>> cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c<br>> >>>>>>>>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c<br>> >>>>>>>>>> cm3/m3-sys/m3front/src/misc/: Marker.m3<br>> >>>>>>>>>> cm3/m3-sys/m3front/src/stmts/: TryFinStmt.m3 TryStmt.m3<br>> >>>>>>>>>> cm3/m3-sys/m3middle/src/: M3RT.i3 M3RT.m3 Target.i3 Target.m3<br>> >>>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>>> Log message:<br>> >>>>>>>>>> use: extern INTEGER Csetjmp__Jumpbuf_size /* = sizeof(jmp_buf);<br>> >>>>>>>>>> alloca(Csetjmp__Jumpbuf_size)<br>> >>>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>>> to allocate jmp_buf<br>> >>>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>>> - eliminates a large swath of target-dependent code<br>> >>>>>>>>>> - allows for covering up the inability to declare<br>> >>>>>>>>>> types with alignment > 64 bits<br>> >>>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>>> It is, granted, a little bit slower, in an already prety slow path.<br>> >>>>>>>>>> Note that alloca isn't actually a function call, at least with gcc backend.<br>> >>>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>>><span class="Apple-converted-space"> </span><br>> >>>>>><span class="Apple-converted-space"> </span><br>> >>>>><span class="Apple-converted-space"> </span><br>> >>>><span class="Apple-converted-space"> </span><br>> >>><span class="Apple-converted-space"> </span><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>