On 6/5/20 10:40 AM, Tom Gardner wrote:> On 05/06/20 13:04, Phil Hobbs wrote: >> On 2020-06-05 07:00, Tom Gardner wrote: >>> On 05/06/20 09:28, Phil Hobbs wrote: >>>> On 2020-06-05 03:38, Tom Gardner wrote: >>>>> On 05/06/20 02:51, Phil Hobbs wrote: >>>>>> On 2020-06-04 12:42, Tom Gardner wrote: >>>>>>> On 04/06/20 17:22, jlarkin@highlandsniptechnology.com wrote: >>>>>>>> On Thu, 4 Jun 2020 16:10:06 +0100, Tom Gardner >>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>> >>>>>>>>> On 04/06/20 00:59, John Larkin wrote: >>>>>>>>>> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner >>>>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>>> >>>>>>>>>>> On 03/06/20 21:21, John Larkin wrote: >>>>>>>>>>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >>>>>>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> The similarities outweigh the differences. >>>>>>>>>>>> >>>>>>>>>>>> The similarities of that statement, six times, are tedious. >>>>>>>>>>> >>>>>>>>>>> Your misapprehensions on this topic are legion >>>>>>>>>>> and repetitive. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Do you design electronics? >>>>>>>>>>> >>>>>>>>>>> I did, for decades. >>>>>>>>>>> >>>>>>>>>>> I also designed and implemented server-side software >>>>>>>>>>> for decades. >>>>>>>>>>> >>>>>>>>>>> Do you implement such software? >>>>>>>>>>> >>>>>>>>>>> (I believe you have said you leave that to others.) >>>>>>>>>> >>>>>>>>>> I wrote two compilers and three pre-emptive RTOSs and maybe a >>>>>>>>>> hundred >>>>>>>>>> embedded programs, >>>>>>>>> It is worth pointing out that all of those examples are >>>>>>>>> (almost certainly) very different to general purpose software >>>>>>>>> and, especially, to application servers and the applications >>>>>>>>> that run within them. >>>>>>>> >>>>>>>> What's not general about an RTOS? Thousands of units were sold. >>>>>>> >>>>>>> It is a single specialised program than can be used in >>>>>>> different end equipment. >>>>>>> >>>>>>> There's far more to software and software development >>>>>>> than that. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Ditto your organisation and the organisations that write/maintain >>>>>>>>> such codebases. >>>>>>>>> >>>>>>>>> Thus it is unsurprising that you do not understand modern >>>>>>>>> medium/large scale software and software practices. Especially >>>>>>>>> the congruences with medium/large scale hardware. >>>>>>>> >>>>>>>> This is an electronic design group. I deal with the software that >>>>>>>> makes electronic instruments work. My relationship to servers is >>>>>>>> that >>>>>>>> I have to talk to them, feed them javascript and UDP packets and >>>>>>>> such. >>>>>>> >>>>>>> No doubt. >>>>>>> >>>>>>> But it confirms that you have no experience of creating >>>>>>> large-scale software systems using modern techniques. >>>>>>> >>>>>>> It is therefore unsurprising that you haven't understood >>>>>>> the congruences with hardware. >>>>>> >>>>>> Congruences between large scale software "using modern techniques" >>>>>> and hardware? Interesting! Since you're obviously expert in both, >>>>>> I'd like to learn more. >>>>> >>>>> More of a jack of all trades and master of none, by choice. >>>>> That has advantages and disadvantages. >>>>> >>>>> >>>>>> What are they, exactly? >>>>> >>>>> That would take a /long/ time to discuss, especially if >>>>> half the concepts are unfamiliar to the audience. >>>>> To take /one/ example >>>>> - how application server frameworks are designed >>>>> and implemented >>>>> - design patterns in the applications' components >>>>> and the way they are composed to form an application, >>>>> - design patterns used to communicate with the outside >>>>> world, >>>>> - antipatterns found in politics, development and design >>>>> >>>>> It is a good topic for a conversation in pubs. >>>>> >>>>> I normally start it by provocatively asking someone to >>>>> distinguish between hardware and software. They normally >>>>> claim it is obvious and come up with a definition. Then >>>>> I introduce them to examples that don't fit their definition. >>>>> Rinse and repeat. > >>>>> Sometimes it can take a long time to realise what the >>>>> proponents of a particular technique are doing, because >>>>> they use unfamiliar terms to describe things that are >>>>> standard in other fields. >>>>> >>>>> Some examples: >>>>> - Jackson's Structured Programming >>>>> - Harel StateCharts >>>>> - many of the more esoteric UML diagrams >>>>> - Hatley and Pirbhai's Strategies for Realtime Systems >>>>> Specification, as successfully used for the Boeing 777 >>>>> - and, obviously, object oriented programming >>>> >>>> So where are the applications to hardware? Even one detailed >>>> example would be interesting. >>> >>> Not application so much as a lack of difference between >>> hardware and software. >>> >>> Harel StateCharts are a formalisation of finite state >>> machine diagrams, which can obviously be implemented >>> in hardware, software, or a combination of the two. >>> >>> UML diagrams are so legion that it is embarassing. >>> The "Unified" is not far off the superset of diagrams >>> from other methodologies. The the well known ones are >>> class hierarchy diagrams, there are also "swimlane >>> interaction" diagrams, and some that are hierarchical >>> structural compositions of software components - just >>> like hierarchical schematics complete with i/o ports >>> connected by wires. >>> >>> Hatley and Pirbhai is particularly interesting. >>> They have two parallel decomposition hierarchies: >>> specification and implementation. Any of the >>> subcomponents can be specified in any way convenient, >>> e.g. FSMs. >>> >>> Every element in the specification hierarchy must >>> have one or more corresponding entities in the >>> implementation hierarchy, and they can be hardware, >>> software, mechanical etc. >>> >>> While the specification hierarchy is almost completely >>> executable (and there may be tools to do that), the >>> only part that Hatley And Pirbhai automated was a >>> database that tracked the complex mappings between >>> the various parts of the specification and >>> implementation hierarchy components. In aerospace >>> trackability is rather important. >>> >>> In the enterprise arena, many patterns are recognisable, >>> some even with accurately suggestive names such as >>> "filter", "multiplexer", "demultiplexer", "event", >>> "asynchronous X", "synchronous X", "control bus", >>> "message bus", "channel". >>> >>> One of many starting points is >>> https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html >>> >> >> Okay, so you don't actually have any hardware examples. A pity. > > True, I don't have a Boeing 777.Or even a Yugo, apparently. ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net https://hobbs-eo.com
KiCad Spice, Anyone Tried It?
Started by ●June 2, 2020
Reply by ●June 5, 20202020-06-05
Reply by ●June 5, 20202020-06-05
On 05/06/2020 15:33, pcdhobbs@gmail.com wrote:> You're fogging, which is your usual MO when anyone calls you on your > BS. > > In your most recent one, the return value is thrown away, which the > compiler of course noticed. >No, it is not thrown away - it is written to an externally accessible variable. Please look at the code before resorting to insults.> These are all toys, not big_calculation()s done for some actual > reason other than saving your ass. > > How about a counterexample using the code I called you on, using > actual embedded code with an actual output that gets used for > something real? >I have never suggested that a compiler would /always/ re-order code. I have said it is always allowed to re-order it, as long as all observable behaviour has the right values and the right order. I started with an example to explain the kind of re-orderings that are allowed. I have since then shown you several examples where they are not only allowed, but where a compiler clearly does such re-ordering in practice. I have shown that semicolons do not affect ordering, nor do function calls (when the compiler knows the definition of the function, and therefore knows all about its observable behaviour). I have shown that you are wrong in your ideas about how C is defined. Would you like chapter and verse from the C standard? You can find the latest free version (the last draft of C18, N2346) online and look at 5.1.2.3p6 under "Program execution" : """ The least requirements on a conforming implementation are: — Volatile accesses to objects are evaluated strictly according to the rules of the abstract machine. — At program termination, all data written into files shall be identical to the result that execution of the program according to the abstract semantics would have produced. — The input and output dynamics of interactive devices shall take place as specified in 7.21.3. The intent of these requirements is that unbuffered or line-buffered output appear as soon as possible, to ensure that prompting messages actually appear prior to a program waiting for input. This is the observable behavior of the program. """ What do you consider a "toy" example, and what do you consider a "real" example? I suspect you view "toy" as "gcc re-orders the code, proving David's point" and "real" as "gcc doesn't happen to re-order the code at the moment, letting me keep my illusions". But just as a final example, along with a local "big_calc" function I'll throw in some library maths functions, including conversions back and forth between integers and doubles. #include <math.h> extern volatile unsigned char pin; unsigned int t = 1; unsigned int big_calc(unsigned int x) { unsigned int y = x * x; unsigned int z = sin(x); return sqrt(y * y + 2 * z + 3 * y + 4); } void foo(void) { pin = 1; t = big_calc(t); pin = 0; } Code generated with -O2 -ffast-math : (The "-ffast-math" lets the compiler use the sqrtsd instruction without checking for a safe operand.) foo: mov eax, DWORD PTR t[rip] pxor xmm0, xmm0 push rbx mov BYTE PTR pin[rip], 1 cvtsi2sd xmm0, rax mov ebx, eax imul ebx, eax call sin lea eax, [rbx+3] mov BYTE PTR pin[rip], 0 cvttsd2si rdx, xmm0 pxor xmm0, xmm0 imul eax, ebx pop rbx lea eax, [rax+4+rdx*2] cvtsi2sd xmm0, rax sqrtsd xmm0, xmm0 cvttsd2si rax, xmm0 mov DWORD PTR t[rip], eax ret Look at how much code is moved /after/ "pin = 0" is executed. The "sin" function /may/ have observable behaviour or side-effects that lead to observable behaviour later, such as changing the value of "errno". Thus it must be ordered within the "pin = 1;", "pin = 0;" pair. The rest is re-ordered according to what the scheduler thinks will be most efficient use of the cpu's execution units - there is no need to relate the order to the volatile accesses. <https://godbolt.org/z/MgEnKx> Now, are you still going to deny what I have demonstrated, explained, and quoted from the language standards, or are you going to continue to believe that a volatile access forces an order on everything else?
Reply by ●June 5, 20202020-06-05
On 05/06/2020 16:13, jlarkin@highlandsniptechnology.com wrote:> Yes. One trick is to force a c calculation to include the state of a > pin or something external, in a way that can't be optimized out. *We* > know that the pin is always low, because we soldered it to ground. >That's it, yes. But you don't need an actual pin - make a volatile variable that you set to 0 (or whatever you like), make your calculation depend on reading it. Then write the output of the calculation to a volatile variable. As Tom said, it's not rocket science - but you /do/ need to put something like this in place if you want reliable timing.> Or write an expression that is complex enough that the compiler can't > figure out how to optimize it away; create a handy dirty variable. >That's not a good idea. "Complex enough" might work on this compiler with these flags, and then fail with a different compiler or different settings. And your "complex enough" expression starts to cause more significant timing issues. Use the volatile method described above. It is simple, cheap, and guaranteed to work. In my book, that beats complex, expensive, and merely tested to work.
Reply by ●June 5, 20202020-06-05
On 05/06/2020 15:58, jlarkin@highlandsniptechnology.com wrote:> On Fri, 5 Jun 2020 04:45:44 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> On 2020-06-05 04:05, David Brown wrote: >>> On 05/06/2020 04:24, jlarkin@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>>> <david.brown@hesbynett.no> wrote: >>>> >>>> >>>>>> >>>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>>> their code does. You can often relate the pulse widths to paths >>>>>> through the code. >>>>>> >>>>> >>>>> A scope can be a fine tool for measuring code performance. I like to >>>>> make sure there are a few test pins on our boards that can be connected >>>>> to an oscilloscope precisely for measuring critical code. Not all >>>>> programmers understand how to instrument code for such measurements, >>>>> unfortunately. >>>> >>>> Raise a port pin at the start of the routine, and drop it at the end. >>>> Maybe invert it a couple of times, at interesting points. >>> >>> And how do you know that you are raising it at the /real/ start of the >>> routine, and dropping it at the /real/ end of the routine? I've seen >>> people write code like : >>> >>> ... >>> set_pin_hi_macro(); >>> x = big_calculation(); >>> set_pin_lo_macro(); >>> ... >>> >>> without realising that the compiler (and processor, for more advanced >>> cpus) can re-order a lot of that and make the timing seriously unrealistic. >> >> All the embedded stuff I recall doing in C/C++ defines the various port >> registers as volatile, so the compiler can't play games like that.The compiler isn't playing games with the volatile stuff. It is playing games with all the non-volatile stuff, and it's allowed to do that. Indeed, you /want/ it to do that - that's what optimisation is about.> > Right. If the port was treated as a local variable, both the set and > the clear would be optimized out, since they obviously don't do > anything. > > Playing with compiler optimization options can have radical effects.It can have radical effects on timings and code size - but if it has any effect on program operation and correctness (except when related to timings and size), then the source code is flawed.> We had one case where it took a lot of experimenting with a c compiler > to get it anywhere as fast a runtime as my PowerBasic program. It > started down 4:1 and finally got about 80% as fast. >
Reply by ●June 5, 20202020-06-05
On 6/5/20 11:29 AM, David Brown wrote:> On 05/06/2020 15:33, pcdhobbs@gmail.com wrote: >> You're fogging, which is your usual MO when anyone calls you on your >> BS. >> >> In your most recent one, the return value is thrown away, which the >> compiler of course noticed. >> > > No, it is not thrown away - it is written to an externally accessible > variable. Please look at the code before resorting to insults. > >> These are all toys, not big_calculation()s done for some actual >> reason other than saving your ass. >> >> How about a counterexample using the code I called you on, using >> actual embedded code with an actual output that gets used for >> something real? >> > > I have never suggested that a compiler would /always/ re-order code. I > have said it is always allowed to re-order it, as long as all observable > behaviour has the right values and the right order. I started with an > example to explain the kind of re-orderings that are allowed. I have > since then shown you several examples where they are not only allowed, > but where a compiler clearly does such re-ordering in practice. > > I have shown that semicolons do not affect ordering, nor do function > calls (when the compiler knows the definition of the function, and > therefore knows all about its observable behaviour). I have shown that > you are wrong in your ideas about how C is defined. > > Would you like chapter and verse from the C standard? You can find the > latest free version (the last draft of C18, N2346) online and look at > 5.1.2.3p6 under "Program execution" : > > """ > The least requirements on a conforming implementation are: > > — Volatile accesses to objects are evaluated strictly according to the > rules of the abstract machine. > > — At program termination, all data written into files shall be identical > to the result that execution of the program according to the abstract > semantics would have produced. > > — The input and output dynamics of interactive devices shall take place > as specified in 7.21.3. The intent of these requirements is that > unbuffered or line-buffered output appear as soon as possible, to ensure > that prompting messages actually appear prior to a program waiting for > input. > > This is the observable behavior of the program. > """ > > > What do you consider a "toy" example, and what do you consider a "real" > example? I suspect you view "toy" as "gcc re-orders the code, proving > David's point" and "real" as "gcc doesn't happen to re-order the code at > the moment, letting me keep my illusions". > > But just as a final example, along with a local "big_calc" function I'll > throw in some library maths functions, including conversions back and > forth between integers and doubles. > > #include <math.h> > > extern volatile unsigned char pin; > > unsigned int t = 1; > > unsigned int big_calc(unsigned int x) { > unsigned int y = x * x; > unsigned int z = sin(x); > return sqrt(y * y + 2 * z + 3 * y + 4); > } > > void foo(void) { > pin = 1; > > t = big_calc(t); > > pin = 0; > } > > > Code generated with -O2 -ffast-math : > (The "-ffast-math" lets the compiler use the sqrtsd instruction without > checking for a safe operand.) > > foo: > mov eax, DWORD PTR t[rip] > pxor xmm0, xmm0 > push rbx > mov BYTE PTR pin[rip], 1 > cvtsi2sd xmm0, rax > mov ebx, eax > imul ebx, eax > call sin > lea eax, [rbx+3] > mov BYTE PTR pin[rip], 0 > cvttsd2si rdx, xmm0 > pxor xmm0, xmm0 > imul eax, ebx > pop rbx > lea eax, [rax+4+rdx*2] > cvtsi2sd xmm0, rax > sqrtsd xmm0, xmm0 > cvttsd2si rax, xmm0 > mov DWORD PTR t[rip], eax > ret > > Look at how much code is moved /after/ "pin = 0" is executed. > > The "sin" function /may/ have observable behaviour or side-effects that > lead to observable behaviour later, such as changing the value of > "errno". Thus it must be ordered within the "pin = 1;", "pin = 0;" > pair. The rest is re-ordered according to what the scheduler thinks > will be most efficient use of the cpu's execution units - there is no > need to relate the order to the volatile accesses. > > > <https://godbolt.org/z/MgEnKx> > > > Now, are you still going to deny what I have demonstrated, explained, > and quoted from the language standards, or are you going to continue to > believe that a volatile access forces an order on everything else?We're talking about embedded code, using _your_ original example. One square root is hardly a big_calculation(). Your square rooting function doesn't do anything useful, because once again its return value is thrown away, and is therefore invisible because it's useless. The compiler may not be smart enough to get rid of it altogether, but otherwise it's just like one of your previous examples. If you want to get away with running down stupid knuckle-dragger embedded types in an electronics design group, you're really going to have to do better than that. If one made a silly mistake, and coded something useless like that that could be optimized away, instrumenting it with a pin toggle would show the problem very quickly. That's one way that instrumenting it is useful. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net https://hobbs-eo.com
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 15:30:04 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:>On 05/06/20 14:43, jlarkin@highlandsniptechnology.com wrote: >> On Fri, 5 Jun 2020 08:49:38 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 05/06/20 03:24, jlarkin@highlandsniptechnology.com wrote: >>>> On Thu, 4 Jun 2020 22:30:14 +0200, David Brown >>>> <david.brown@hesbynett.no> wrote: >>>> >>>> >>>>>> >>>>>> That's what I have to do, use an oscilloscope to show programmers what >>>>>> their code does. You can often relate the pulse widths to paths >>>>>> through the code. >>>>>> >>>>> >>>>> A scope can be a fine tool for measuring code performance. I like to >>>>> make sure there are a few test pins on our boards that can be connected >>>>> to an oscilloscope precisely for measuring critical code. Not all >>>>> programmers understand how to instrument code for such measurements, >>>>> unfortunately. >>>> >>>> Raise a port pin at the start of the routine, and drop it at the end. >>>> Maybe invert it a couple of times, at interesting points. >>> >>> Yes, it isn't rocket science. >> >> I know Fellows of big aerospace companies, software guys, who aren't >> sure which end of an oscilloscope goes up. They can't estimate >> runtines within 10:1, so they grossly overkill on compute power. > >As long as they have other skills that complement yours, that sounds like an >ideal combination. >Jack Sprat could eat no fat. >His wife could eat no lean. >So together they scraped >the platter clean. > > >> One of them is playing with those raspberry pi things at home. I'm >> going to send him an oscilloscope. > >It is always good to be able to help people step into >areas where they are unsure and have things to learn. > >That's easy to do with kids, less so with adults that >have appearances to defend. > > >> >>> >>> If the test point reflects the "idle" time, you can even >>> put a voltmeter (preferable moving coil!) on it to visualise >>> the processor utilisation. Dirty, but quick. >>> >>> >>>> We did one test on a Zynq, dual 600 MHz ARMs running the usual Linux. >>>> One program just toggled a pin as hard as it could, and we looked at >>>> that on a scope to see how much other things suspended the loop. We'd >>>> see occasional long highs or lows, "long" being numbers like 20 us. I >>>> was impressed. The linux periodic interrupt only took a few >>>> microseconds. >>> >>> Did you form an opinion as to what caused the pauses? >> >> There was an obvious linux timer IRQ, always there, at 1 KHz as I >> recall. Things like ethernet activity added less regular timeouts from >> the hard loop. But the worst stackup that we saw was under 40 us, and >> rare. > >In hard realtime, you are only interested in the worst >case; nothing else matters. > >That's why "measure and hope you've spotted worst case" >is so unappealing.Set the scope to infinite persistance and run over a weekend. 20 billion experiments should be enough.> > >> Linux, I understand, allows weak suggestion of what to run on which >> CPU, which we did, and that seemed to help. We didn't research or >> document this extensively, because it became obvious that we could run >> our state loops and such plenty often enough, and that we should do >> some of our math (like summing the means and squares of ADC samples, >> for RMS) in the FPGA. > >Sounds sane. Processors intimately coupled with FPGA >are /one/ good starting point for many interesting things.One nice thing about Zynq is that the cpu-to-fpga-register accesses can be very fast, and don't need a zillion pcb traces between chips. And a Zynq knows how to boot everything from one plug-in micro SD card.> >I haven't investigated real time linux on the grounds >that it feels as if the proponents only have hammers >in their toolkit. > > >>> Did the "other stuff" manage/avoid interfering with >>> the caches? >> >> Don't know. We just scoped the gross timeouts. > >Fine if the processors are grossly underused.I have one board with 13 small ARM chips, one manager and 12 isolated channel processors. The channels are LPC1754s that run my ADC/filter/control/DAC loop in an IRQ at 200 KHz. We ran the CPU clocks at 70 MHz to save power. That code was optimized by oscilloscope. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 11:14:44 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>On 6/5/20 10:15 AM, jlarkin@highlandsniptechnology.com wrote: >> On Fri, 5 Jun 2020 08:58:15 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 04/06/20 21:08, John Larkin wrote: >>>> On Thu, 4 Jun 2020 21:43:14 +0200, David Brown >>>> <david.brown@hesbynett.no> wrote: >>>>> >>>>> All sorts of things make it difficult to calculate accurately the run >>>>> time of non-trivial code. You might be able to make some rough >>>>> estimates, but generally measurement is better. >>>> >>>> That's what I have to do, use an oscilloscope to show programmers what >>>> their code does. You can often relate the pulse widths to paths >>>> through the code. >>> >>> I've used analogous techniques in telecoms applications >>> running in both and out of JAIN servers and. It was >>> great for: >>> - astounding people at how fast/efficient my design >>> strategy and code was compared with their previous >>> products >>> - demonstrating to other companies exactly where their >>> code was faulty >>> - thus avoiding CEOs and lawyers becoming involved :) >>> >>> The biggest problem was getting softies to understand >>> why the mean value is so crude, and that a 95% value >>> was much more useful. >> >> Set the scope to infinite persistance, and run overnight. >> >> >> >Newer scopes have colour histogramming to show rare events as being >rare, which is nice for that sort of thing. If I ever buy a bnew fancy >scope, that and the number of traces per second will be why. >We have the 4-ch 7 GHz $50K LeCroy box. It does wonderful things that are approximately impossible to figure out how to use. The HELP was obviously composed by a programmer, or maybe an intern. My favorite feature on my 500 Mhz Rigol scope is the button DEFAULT SETUP. Just be an oscilloscope, OK? -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On Fri, 5 Jun 2020 11:17:37 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>On 6/5/20 10:40 AM, Tom Gardner wrote: >> On 05/06/20 13:04, Phil Hobbs wrote: >>> On 2020-06-05 07:00, Tom Gardner wrote: >>>> On 05/06/20 09:28, Phil Hobbs wrote: >>>>> On 2020-06-05 03:38, Tom Gardner wrote: >>>>>> On 05/06/20 02:51, Phil Hobbs wrote: >>>>>>> On 2020-06-04 12:42, Tom Gardner wrote: >>>>>>>> On 04/06/20 17:22, jlarkin@highlandsniptechnology.com wrote: >>>>>>>>> On Thu, 4 Jun 2020 16:10:06 +0100, Tom Gardner >>>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>> >>>>>>>>>> On 04/06/20 00:59, John Larkin wrote: >>>>>>>>>>> On Thu, 4 Jun 2020 00:25:35 +0100, Tom Gardner >>>>>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 03/06/20 21:21, John Larkin wrote: >>>>>>>>>>>>> On Wed, 3 Jun 2020 17:33:30 +0100, Tom Gardner >>>>>>>>>>>>> <spamjunk@blueyonder.co.uk> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The similarities outweigh the differences. >>>>>>>>>>>>> >>>>>>>>>>>>> The similarities of that statement, six times, are tedious. >>>>>>>>>>>> >>>>>>>>>>>> Your misapprehensions on this topic are legion >>>>>>>>>>>> and repetitive. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Do you design electronics? >>>>>>>>>>>> >>>>>>>>>>>> I did, for decades. >>>>>>>>>>>> >>>>>>>>>>>> I also designed and implemented server-side software >>>>>>>>>>>> for decades. >>>>>>>>>>>> >>>>>>>>>>>> Do you implement such software? >>>>>>>>>>>> >>>>>>>>>>>> (I believe you have said you leave that to others.) >>>>>>>>>>> >>>>>>>>>>> I wrote two compilers and three pre-emptive RTOSs and maybe a >>>>>>>>>>> hundred >>>>>>>>>>> embedded programs, >>>>>>>>>> It is worth pointing out that all of those examples are >>>>>>>>>> (almost certainly) very different to general purpose software >>>>>>>>>> and, especially, to application servers and the applications >>>>>>>>>> that run within them. >>>>>>>>> >>>>>>>>> What's not general about an RTOS? Thousands of units were sold. >>>>>>>> >>>>>>>> It is a single specialised program than can be used in >>>>>>>> different end equipment. >>>>>>>> >>>>>>>> There's far more to software and software development >>>>>>>> than that. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> Ditto your organisation and the organisations that write/maintain >>>>>>>>>> such codebases. >>>>>>>>>> >>>>>>>>>> Thus it is unsurprising that you do not understand modern >>>>>>>>>> medium/large scale software and software practices. Especially >>>>>>>>>> the congruences with medium/large scale hardware. >>>>>>>>> >>>>>>>>> This is an electronic design group. I deal with the software that >>>>>>>>> makes electronic instruments work. My relationship to servers is >>>>>>>>> that >>>>>>>>> I have to talk to them, feed them javascript and UDP packets and >>>>>>>>> such. >>>>>>>> >>>>>>>> No doubt. >>>>>>>> >>>>>>>> But it confirms that you have no experience of creating >>>>>>>> large-scale software systems using modern techniques. >>>>>>>> >>>>>>>> It is therefore unsurprising that you haven't understood >>>>>>>> the congruences with hardware. >>>>>>> >>>>>>> Congruences between large scale software "using modern techniques" >>>>>>> and hardware? Interesting!� Since you're obviously expert in both, >>>>>>> I'd like to learn more. >>>>>> >>>>>> More of a jack of all trades and master of none, by choice. >>>>>> That has advantages and disadvantages. >>>>>> >>>>>> >>>>>>> What are they, exactly? >>>>>> >>>>>> That would take a /long/ time to discuss, especially if >>>>>> half the concepts are unfamiliar to the audience. >>>>>> To take /one/ example >>>>>> ��- how application server frameworks are designed >>>>>> ��� and implemented >>>>>> ��- design patterns in the applications' components >>>>>> ��� and the way they are composed to form an application, >>>>>> ��- design patterns used to communicate with the outside >>>>>> ��� world, >>>>>> ��- antipatterns found in politics, development and design >>>>>> >>>>>> It is a good topic for a conversation in pubs. >>>>>> >>>>>> I normally start it by provocatively asking someone to >>>>>> distinguish between hardware and software. They normally >>>>>> claim it is obvious and come up with a definition. Then >>>>>> I introduce them to examples that don't fit their definition. >>>>>> Rinse and repeat. > >>>>>> Sometimes it can take a long time to realise what the >>>>>> proponents of a particular technique are doing, because >>>>>> they use unfamiliar terms to describe things that are >>>>>> standard in other fields. >>>>>> >>>>>> Some examples: >>>>>> ��- Jackson's Structured Programming >>>>>> ��- Harel StateCharts >>>>>> ��- many of the more esoteric UML diagrams >>>>>> ��- Hatley and Pirbhai's Strategies for Realtime Systems >>>>>> ��� Specification, as successfully used for the Boeing 777 >>>>>> ��- and, obviously, object oriented programming >>>>> >>>>> So where are the applications to hardware?�� Even one detailed >>>>> example would be interesting. >>>> >>>> Not application so much as a lack of difference between >>>> hardware and software. >>>> >>>> Harel StateCharts are a formalisation of finite state >>>> machine diagrams, which can obviously be implemented >>>> in hardware, software, or a combination of the two. >>>> >>>> UML diagrams are so legion that it is embarassing. >>>> The "Unified" is not far off the superset of diagrams >>>> from other methodologies. The the well known ones are >>>> class hierarchy diagrams, there are also "swimlane >>>> interaction" diagrams, and some that are hierarchical >>>> structural compositions of software components - just >>>> like hierarchical schematics complete with i/o ports >>>> connected by wires. >>>> >>>> Hatley and Pirbhai is particularly interesting. >>>> They have two parallel decomposition hierarchies: >>>> specification and implementation. Any of the >>>> subcomponents can be specified in any way convenient, >>>> e.g. FSMs. >>>> >>>> Every element in the specification hierarchy must >>>> have one or more corresponding entities in the >>>> implementation hierarchy, and they can be hardware, >>>> software, mechanical etc. >>>> >>>> While the specification hierarchy is almost completely >>>> executable (and there may be tools to do that), the >>>> only part that Hatley And Pirbhai automated was a >>>> database that tracked the complex mappings between >>>> the various parts of the specification and >>>> implementation hierarchy components. In aerospace >>>> trackability is rather important. >>>> >>>> In the enterprise arena, many patterns are recognisable, >>>> some even with accurately suggestive names such as >>>> "filter", "multiplexer", "demultiplexer", "event", >>>> "asynchronous X", "synchronous X", "control bus", >>>> "message bus", "channel". >>>> >>>> One of many starting points is >>>> https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html >>>> >>> >>> Okay, so you don't actually have any hardware examples.� A pity. >> >> True, I don't have a Boeing 777. > >Or even a Yugo, apparently. ;) > >Cheers > >Phil HobbsOr an oscilloscope. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●June 5, 20202020-06-05
On 05/06/2020 17:49, Phil Hobbs wrote:> On 6/5/20 11:29 AM, David Brown wrote: >> On 05/06/2020 15:33, pcdhobbs@gmail.com wrote: >>> You're fogging, which is your usual MO when anyone calls you on your >>> BS. >>> >>> In your most recent one, the return value is thrown away, which the >>> compiler of course noticed. >>> >> >> No, it is not thrown away - it is written to an externally accessible >> variable. Please look at the code before resorting to insults. >> >>> These are all toys, not big_calculation()s done for some actual >>> reason other than saving your ass. >>> >>> How about a counterexample using the code I called you on, using >>> actual embedded code with an actual output that gets used for >>> something real? >>> >> >> I have never suggested that a compiler would /always/ re-order code. I >> have said it is always allowed to re-order it, as long as all observable >> behaviour has the right values and the right order. I started with an >> example to explain the kind of re-orderings that are allowed. I have >> since then shown you several examples where they are not only allowed, >> but where a compiler clearly does such re-ordering in practice. >> >> I have shown that semicolons do not affect ordering, nor do function >> calls (when the compiler knows the definition of the function, and >> therefore knows all about its observable behaviour). I have shown that >> you are wrong in your ideas about how C is defined. >> >> Would you like chapter and verse from the C standard? You can find the >> latest free version (the last draft of C18, N2346) online and look at >> 5.1.2.3p6 under "Program execution" : >> >> """ >> The least requirements on a conforming implementation are: >> >> — Volatile accesses to objects are evaluated strictly according to the >> rules of the abstract machine. >> >> — At program termination, all data written into files shall be identical >> to the result that execution of the program according to the abstract >> semantics would have produced. >> >> — The input and output dynamics of interactive devices shall take place >> as specified in 7.21.3. The intent of these requirements is that >> unbuffered or line-buffered output appear as soon as possible, to ensure >> that prompting messages actually appear prior to a program waiting for >> input. >> >> This is the observable behavior of the program. >> """ >> >> >> What do you consider a "toy" example, and what do you consider a "real" >> example? I suspect you view "toy" as "gcc re-orders the code, proving >> David's point" and "real" as "gcc doesn't happen to re-order the code at >> the moment, letting me keep my illusions". >> >> But just as a final example, along with a local "big_calc" function I'll >> throw in some library maths functions, including conversions back and >> forth between integers and doubles. >> >> #include <math.h> >> >> extern volatile unsigned char pin; >> >> unsigned int t = 1; >> >> unsigned int big_calc(unsigned int x) { >> unsigned int y = x * x; >> unsigned int z = sin(x); >> return sqrt(y * y + 2 * z + 3 * y + 4); >> } >> >> void foo(void) { >> pin = 1; >> >> t = big_calc(t); >> >> pin = 0; >> } >> >> >> Code generated with -O2 -ffast-math : >> (The "-ffast-math" lets the compiler use the sqrtsd instruction without >> checking for a safe operand.) >> >> foo: >> mov eax, DWORD PTR t[rip] >> pxor xmm0, xmm0 >> push rbx >> mov BYTE PTR pin[rip], 1 >> cvtsi2sd xmm0, rax >> mov ebx, eax >> imul ebx, eax >> call sin >> lea eax, [rbx+3] >> mov BYTE PTR pin[rip], 0 >> cvttsd2si rdx, xmm0 >> pxor xmm0, xmm0 >> imul eax, ebx >> pop rbx >> lea eax, [rax+4+rdx*2] >> cvtsi2sd xmm0, rax >> sqrtsd xmm0, xmm0 >> cvttsd2si rax, xmm0 >> mov DWORD PTR t[rip], eax >> ret >> >> Look at how much code is moved /after/ "pin = 0" is executed. >> >> The "sin" function /may/ have observable behaviour or side-effects that >> lead to observable behaviour later, such as changing the value of >> "errno". Thus it must be ordered within the "pin = 1;", "pin = 0;" >> pair. The rest is re-ordered according to what the scheduler thinks >> will be most efficient use of the cpu's execution units - there is no >> need to relate the order to the volatile accesses. >> >> >> <https://godbolt.org/z/MgEnKx> >> >> >> Now, are you still going to deny what I have demonstrated, explained, >> and quoted from the language standards, or are you going to continue to >> believe that a volatile access forces an order on everything else? > > We're talking about embedded code, using _your_ original example. One > square root is hardly a big_calculation().Show me a reference in the C standards where it explains that the ordering rules are different for big calculations and small calculations. You can't? You are just desperately trying to avoid learning something new. I don't get that - it really is hard to comprehend. Perhaps you feel you've invested too much in calling my posts BS, and that admitting you were wrong about this would be a blow to your ego. I am sure I could make a "big" calculation example. When you use a modern compiler with more optimisations, especially link-time optimisation letting it pull in code from all over the place and inline it together, I'm confident I'd see at least some of it moved within the "pin = 1; pin = 0;" pair. But I'm equally confident that any such effort would be wasted on you, as you'd find new reasons to claim it was "toy" or "not big enough".> > Your square rooting function doesn't do anything useful, because once > again its return value is thrown away, and is therefore invisible > because it's useless.Again, did you even bother looking at the source code? The result is stored and available for other code - the compiler /can't/ throw it away. Did you look at the generated code? The square root opcode is staring you in the face. It is not invisible or thrown away, because that would be breaking the rules of C.> The compiler may not be smart enough to get rid > of it altogether, but otherwise it's just like one of your previous > examples. > > If you want to get away with running down stupid knuckle-dragger > embedded types in an electronics design group, you're really going to > have to do better than that.I don't follow you - are you describing yourself as a stupid knuckle-dragger here? I don't see anyone else in this branch who fails to understand that volatile accesses don't order other code.> > If one made a silly mistake, and coded something useless like that that > could be optimized away, instrumenting it with a pin toggle would show > the problem very quickly. That's one way that instrumenting it is useful. >One last time. Read the code. Look at the generated result. Nothing is optimised away. But the timing instrumentation does not time the calculation.
Reply by ●June 5, 20202020-06-05
On 05/06/20 17:56, David Brown wrote:> You are just desperately trying to avoid learning something new. I don't get > that - it really is hard to comprehend. Perhaps you feel you've invested too > much in calling my posts BS, and that admitting you were wrong about this would > be a blow to your ego.There seems to be a general principle that: - if you are a respected expert in field X - you have some knowledge and experience in field Y - you think you are expert in field Y In gliding circles that is known as the "doctor syndrome"... In middle age a successful doctor takes up gliding, becomes solo, becomes a cross country flyer. Then because they have the money and there's nothing stopping them, they buy themselves the biggest baddest glider. Sooner or later, and despite warnings, they end up dead - because their arrogance couldn't let them admit to themselves that other people knew more.
