On Tue, Apr 8, 2014 at 1:52 AM, smplx wrote: > My take on this entire thread was that it started by taking about GOTO > specific to C but very quickly changed to a discussion of "good vs. > evil" use of GOTO in HLLs in general. In which case I really don't see th= e > point of language relevence. Do you. > I don't know - Colin seems to be the only person who's contributed to the goto discussion who isn't using or referring to C. What's more I have to question whether a language lacking such a basic construct has any relevance to the discussion, as clearly if you don't have higher level loop constructs you have no choice but to use goto. The language is only irrelevant so long as it has such constructs. > >> Which I suppose brings us back to knowing how each type of compiler > >> implements different code statements. > >> > > With a decent optimising compiler, it really shouldn't make any > difference > > testing =3D=3D or !=3D (certainly not when testing a STATUS bit) and if= it's > that > > big a deal what the compiler is doing in terms of exactly how many cycl= es > > or instructions you're using, then you should probably be in assembly - > you > > shouldn't really need to get into how different compilers work as that'= s > > losing the whole point of working in a HLL. > > Sure for normal apps on big machines I'd agree (well as long as you're no= t > doing realtime graphics or low level device drivers). But for embedded > systems programming I couldn't disagree more. > Really? Very, very little of what I've done in embedded systems is actually time or space constrained to the point you're worried about individual instructions. That includes commercial real time DSP apps where I've been doing lots of floating and fixed point calcs and hand optimising the code a huge amount to minimise the number of those for speed reasons, as well as stuff running on low level PICs and AVRs. Code portability and maintainability tends to be far, far more important than wringing every last drop out of the system in most cases. You seem to be missing my point that as soon as it becomes critical how a compiler is working you might as well hand compile (with high level code in comments) as fudge your code in order to make the compiler work in a particular way, which isn't going to be portable or maintainable. Exactly the same applies to realtime graphics and device drivers - I've written those in C without worrying about what the compiler is doing - with a decent compiler you simply select appropriate optimisation levels (they also tend to be the sort of thing where your code needs to be maintainable - the issue of goto introducing vulnerabilities has already been mentioned). No, you've really missed the point here. Please re-read what Colin wrote > here. He is talking about using !=3D0 in preference to using <0 in ***C**= * > as a terminator to a FOR loop ***NOT*** for checking the state of the > carry bit in the status register using the XCSB programming language. OK, I did miss that, as I thought we were still talking about the code he gave and my switching the test from !=3D to =3D=3D for better control flow = - though I ignored the comment about counting down in FOR loops as that is just standard practice for anybody who knows how the underlying architecture works, and you would expect it to be the same for all compilers. Assuming that is that number of instructions is critical - the alternative is only a single instruction extra. Still not really relevant to the discussion of goto, as it is the sort of thing which you can do whilst still writing just as well structured code. I know Colin and I think somewhere along the way he got side tracked. I'm > sure that given more time he would have streamlined his code > significantly. Maybe continuing to use gotos but in a less obsure way. > Though not actually in any more efficient or better structured way than my example of the same code not using gotos. The point being that I was asking for examples where goto was essential for the code and not using it would result in worse code - the example I was given was quite the opposite (and I'm still waiting). Chris --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .