Michael, I was aware of the potential problem of loosing scope on return, but was cognoscente of the potential to annoy various readers with a long email detailing all the issues. So, I kept it a little to short...
Your context save/restore using an M-code seams a nice approach. Please generate and keep some real examples as you have prototyped below. These can be used to develop a regression test suite. I wish you the best of success with implementing these, as I think they will be quite useful. Best regards, EBo -- On Wed, 2 Mar 2011 23:39:49 +0100, Michael Haberler wrote: > Ebo - > > I agree pushing the state (for the purpose of this discussion "the > stuff which can be seen in the 'Active G-Codes' window in Axis") into > an extended stack frame, and restoring that on exit would be a > natural > paradigm - state would become an implicitely local set of variables > > unfortunately automatic save/restore breaks backwards compatibility > since existing code might rely on a subroutine changing global state > - > that change would be wiped out on restoring by subroutine return > > so the problem would mutate from 'subroutines necessarily modify > global state' to 'subroutines cannot modify global state' > > this is why I think explicit (say) M-codes for saving and restoring > state in the call frame would be less invasive - I still could save > all the state but modify global state selectively after restoring the > saved state if needed. > > Here's an example. > > Assume M70 is a hypothetical 'save state in call frame' and M71 is > 'restore global state from call frame if present'. > > Lets assume I have a subroutine which needs g91 temporarily wether > set globally or not (g90/g91 should be unchanged after returning from > call). Lets also assume - for the purpose of the argument - the > subroutine must set spindle rpm to 3000 and feed to 100 *globally*. > > So what I could do - in global code: > > g90 (absolute, dont touch me in the sub) > S100 (this will be overridden by sub) > F20 (that too) > o<magicsub> call > > and in magicsub.ngc: > > o<magicsub> sub > M70 (save state, including - currently - g90, S100, F20) > ...fiddle > G91 (needed locally) > .. fiddle > M71 (restores state to g90,S3000,F100) > S3000 (explicitely set global rpm to 3000) > F100 (explicitely set global feed to 100) > (only return to main after setting global state explicitely) > o<magicsub> endsub > m2 > > basically, leaving out M70/M71 would retain current semantics. > > --- > > disjoint from that particular feature, reflecting the global state in > #5xxx parameters for introspection by the very determined ;-) could > be > useful. > > -Michael > > > > > Am 02.03.2011 um 22:49 schrieb EBo: > >> a couple of thoughts... >> >> From a software engineering perspective this has been solved many >> decades ago. It is problems like this which motivated register >> caching >> in operating system calls. The first thing that I would try if it >> were >> me is to implement a proper context switch as part of the subroutine >> entrance/exit. Doing this will require that you save some >> combination >> of state variables (absolute/relative positioning, etc.) and decide >> what >> happens within the subroutine can be exported out. This is >> basically >> the same as option 3 below, but automated. >> >> just a thought... >> >> EBo -- >> >> On Wed, 2 Mar 2011 22:13:56 +0100, Michael Haberler wrote: >>> a persisting problem with G-code subroutines is the fact that >>> modifying active G-codes, feeds etc modifies them for the calling >>> code >>> too - typical example: probe or tool length offset routines often >>> switch to relative mode and change feed. Probe routine done - dang, >>> should we restore absolute mode? what again was the feed? >>> >>> IMO it is next to impossible to write G-code subroutines which do >>> *not* trample on interpreter state, for the simple reason that >>> there >>> is no way to find out the current state from within the >>> interpreter. >>> >>> I see several solutions to this issue, not necessarily disjoint: >>> >>> 1. mirror the active codes in named read-only parameters. So we >>> would >>> have, among other: >>> #<_g20> and #<_g21> imperial/metric (values 0.0 or 1.0) >>> #<_g90> and #<_g91> absolute /relative mode >>> #<_f> - return current feed value >>> .. >>> 2. mirror same active codes in a range of #5xxx parameters - less >>> coding, more arcane, same effect >>> >>> 3. provide a, say, M-code to save the current active G/M-codes, >>> feeds >>> and speeds in the interpreter stack frame, and either restore on >>> return from subroutine, or explicitely restore with another, say, >>> M-code. >>> >>> >>> >>> I am going to do one of these anyway because I'm just too pissed >>> off >>> not to do it. >>> >>> let me know which one you prefer/consider useful. >>> >>> -Michael >>> >>> >>> ps: >>> for an example for 1) - #<_vmajor>, #<_vminor> - see >>> src/emc/rs274ngc/rs274ngc_pre.cc around lines 718-734 >>> There many several examples for 2) - like #5070 - probe tripped >>> plus >>> a ton of others >>> There is no example for 3) so far. It might be more convenient to >>> use. >>> >>> >>> ------------------------------------------------------------------------------ >>> Free Software Download: Index, Search & Analyze Logs and other IT >>> data in >>> Real-Time with Splunk. Collect, index and harness all the fast >>> moving >>> IT data >>> generated by your applications, servers and devices whether >>> physical, >>> virtual >>> or in the cloud. Deliver compliance at lower cost and gain new >>> business >>> insights. http://p.sf.net/sfu/splunk-dev2dev >>> _______________________________________________ >>> Emc-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> >> >> ------------------------------------------------------------------------------ >> Free Software Download: Index, Search & Analyze Logs and other IT >> data in >> Real-Time with Splunk. Collect, index and harness all the fast >> moving IT data >> generated by your applications, servers and devices whether >> physical, virtual >> or in the cloud. Deliver compliance at lower cost and gain new >> business >> insights. http://p.sf.net/sfu/splunk-dev2dev >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT > data in > Real-Time with Splunk. Collect, index and harness all the fast moving > IT data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new > business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
