Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: John Larkin on 22 May 2010 01:49 On Fri, 21 May 2010 23:42:17 -0500, "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote: >On Fri, 21 May 2010 19:27:11 -0700, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>On Fri, 21 May 2010 17:40:55 -0700, D Yuniskis >><not.going.to.be(a)seen.com> wrote: >> >>>Hi John, >>> >>>John Larkin wrote: >>>> On Fri, 21 May 2010 09:40:00 -0700, D Yuniskis >>>> <not.going.to.be(a)seen.com> wrote: >>>> >>>>> Hi Phil, >>>>> >>>>> Phil Hobbs wrote: >>>>>> On 5/20/2010 2:03 PM, D Yuniskis wrote: >>>>>>> This, I think, is an outgrowth of the same sort of >>>>>>> ridiculous mindset that people initially bring to >>>>>>> *organizing* data. E.g., how many part numbering systems >>>>>>> have data embedded *in* the part number that tries to >>>>>>> describe the item? (isn't that the role of the *description* >>>>>>> tied to the P/N??) People impose structure on things >>>>>>> unnecessarily instead of letting the machine do that on >>>>>>> their behalf. >>>>>>> >>>>>>> E.g., when I started preparing documents, standards, etc. >>>>>>> here, I used a much more commonsense approach: I started >>>>>>> with *1* :> (instead of something artificial like >>>>>>> 1985-SPEC-SFW-001.1 -- the ".1" being a revision level, etc.) >>>>>>> Then, moved on to "2". >>>>>>> >>>>>>> Data should largely be free-form -- except where it *can't* :> >>>>>>> This applies to part numbers, object (file) names, etc. Once >>>>>>> you start imposing artificial structure, you start forcing >>>>>>> things to be "done your way" -- which, typically, exposes >>>>>>> some *flaw* in "your way", later (once you are *very* pregnant!) >>>>>>> >>>>>>> Put smarts in the system to be able to *understand* the data. >>>>>> It's sort of nice to be able to look at a part number and see whether >>>>>> it's a capacitor or a BNC connector, though. That doesn't have to have >>>>>> descriptions embedded in the part number, but it does need a bit of >>>>>> thought, e.g. numbers starting with '0' are subassemblies, '1', >>>>>> resistors, '2', capacitors, and so forth. Takes an extra couple of >>>>>> digits but makes life a lot easier. >>>>> I don't think it works, in the long run. And, I think >>>>> the effort spent trying to figure out *how* to do this >>>>> (and codifying it and ensuring everyone uses the same >>>>> rules) is better used getting better descriptions, better >>>>> search capabilities, etc. >>>> >>>> It is convenient to have all the 0805 resistors in the same part of >>>> the stockroom, and not mixed randomly with transformers and sheet >>>> metal and shrink tubing. Even more convenient to have them in order by >>>> resistance. >>> >>>There's nothing that says part numbers have to be positioned >>>on shelves in sequential order. You track the *location* >>>of a part as part of your inventory control system. So >>>that you are free to put things wherever is most convenient. >> >>Cool. Every part gets a location number that determines their location >>and order on the shelves. So why isn't that the part number? > >...and if you change the inventory location you change all your schematics. If >you obsolete a part you can never use that shelf again? A schematic is a reference drawing that doesn't control anything; it refers to parts by reference designator. Assembly drawings and their associated parts lists control product configuration, and they use part numbers. I'm surprised I have to explain stuff this basic. What doesn't surprise me, any more, is what a horror most material and document control systems are. John
From: Tim Williams on 22 May 2010 02:13 "John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message news:i0gev5ltreatfl8mk6s1ga6a2m9nl1shu3(a)4ax.com... >>There's nothing that says part numbers have to be positioned >>on shelves in sequential order. You track the *location* >>of a part as part of your inventory control system. So >>that you are free to put things wherever is most convenient. > > Cool. Every part gets a location number that determines their location > and order on the shelves. So why isn't that the part number? Bicker, bicker. Concatenate both numbers, hash them, and use the hash code. The number is completely devoid of meaning, and offers instant access to its field in the database. This satisfies both parties, debate over. ;-) Tim -- Deep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms
From: Tim Williams on 22 May 2010 02:31 "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message news:ht6gj5$p8c$1(a)speranza.aioe.org... > It's not a question of how *you* read the code but how > some poor Joe following you will read the code! :> I don't like the idea of some poor Joe modifying my code if he can't even understand it. There's a point where mov a,b ; copy b to a becomes so verbose that it adds absolutely no meaning, serving only to obfuscate useful statements. Supposedly, there was a disassembler which automatically commented, adding exactly this type of superfluous verbosity. I must admit, your comments don't seem to be vacuously verbose, an impressive feat at their density! > E.g., the following snippet is from a keypad handler > (I figure that is easy enough for folks to relate to). > Apologies for the ALL CAPS -- the fragment is 25 years > old. I've snipped bits out of each line to try to get > the line widths down to something more manageable. Heh... last one I did looked like: -=-=-=- uint8_t A, B; .... // Switch debouncer // A = true when open for 3 cycles A = debounce[0] & debounce[1] & debounce[2]; // B == true when closed for 3 cycles B = ~(debounce[0] | debounce[1] | debounce[2]); buttons = ~(A | ~(buttons | B)); debounce[2] = debounce[1]; debounce[1] = debounce[0]; debounce[0] = PINA; -=-=-=- Makes sense, right? No? Well, in this case I have the logic diagram which accompanies the code. ASCII art isn't really my style, though I agree it would be handy here for someone looking at this block in situ. If you haven't decoded the function: it's a block that I'm quite fond of in VHDL. Each button (there are 5, but the whole PINA port is debounced since we get 8 bits/byte -- we'll be masking later when reading the buttons, no need to do it right now) is put into a shift register (which could be a circular list instead of cascaded variables, but it's not speed critical or anything). When all three bits of that register are true (A = 0 & 1 & 2), a flip-flop is set. When all three bits are false (when 0 | 1 | 2 is false), the flip-flop is reset. Actually it's inverted from that, since the buttons are active-low, but that's the jist of it. So it's a filtered, hysteretic debouncer. Perhaps unusually, I think the code looks better in VHDL. You have constructs like "if debounce[0] == '0' and debounce[1] == '0' and ...", which are imperative, more descriptive than an abstract logic function is. VHDL lets you do whatever you want with bits or vectors, whereas processors can't construct "ifs" on a bitwise basis (not without a *lot* more code). Having typed this, maybe I'll paste it in as comment... :-p Tim -- Deep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms
From: D Yuniskis on 22 May 2010 03:49 Hi Tim, Tim Williams wrote: > "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message > news:ht6gj5$p8c$1(a)speranza.aioe.org... >> It's not a question of how *you* read the code but how >> some poor Joe following you will read the code! :> > > I don't like the idea of some poor Joe modifying my code if he can't even > understand it. There's a point where > mov a,b ; copy b to a > becomes so verbose that it adds absolutely no meaning, serving only to > obfuscate useful statements. Agreed. Comments should tell what the *goal* of the code is ("why") and not restate "what it's doing". > Supposedly, there was a disassembler which automatically commented, adding > exactly this type of superfluous verbosity. > > I must admit, your comments don't seem to be vacuously verbose, an > impressive feat at their density! > >> E.g., the following snippet is from a keypad handler >> (I figure that is easy enough for folks to relate to). >> Apologies for the ALL CAPS -- the fragment is 25 years >> old. I've snipped bits out of each line to try to get >> the line widths down to something more manageable. > > Heh... last one I did looked like: > > -=-=-=- > > uint8_t A, B; > > .... > > // Switch debouncer > > // A = true when open for 3 cycles > A = debounce[0] & debounce[1] & debounce[2]; > // B == true when closed for 3 cycles > B = ~(debounce[0] | debounce[1] | debounce[2]); > buttons = ~(A | ~(buttons | B)); > debounce[2] = debounce[1]; > debounce[1] = debounce[0]; > debounce[0] = PINA; > > -=-=-=- > > Makes sense, right? Yup. Though I don't see how *time* gets factored in (no doubt the "samples" are taken periodically so there is something, someplace, that allows you to map "number of consecutive samples" to some "period of time". > No? Well, in this case I have the logic diagram which > accompanies the code. ASCII art isn't really my style, though I agree it > would be handy here for someone looking at this block in situ. > > If you haven't decoded the function: it's a block that I'm quite fond of in > VHDL. Each button (there are 5, but the whole PINA port is debounced since > we get 8 bits/byte -- we'll be masking later when reading the buttons, no > need to do it right now) is put into a shift register (which could be a > circular list instead of cascaded variables, but it's not speed critical or > anything). When all three bits of that register are true (A = 0 & 1 & 2), a > flip-flop is set. When all three bits are false (when 0 | 1 | 2 is false), > the flip-flop is reset. Actually it's inverted from that, since the buttons > are active-low, but that's the jist of it. So it's a filtered, hysteretic > debouncer. The handler I posted debounces only on the releasing edge. I.e., as soon as a button closure is detected, the key "event" is passed to the application (assuming it was a *single* contact closure). The state machine re-arms after it has detected a successful "release" (no closures detected for DEBOUNCE_TIMER interval). Everything is an event. So, you can just as easily pass a "KEYBOARD STUCK" event down the same channel as the keys themselves (simplifies handling at the application layer). Likewise, I could pass BARCODE_READ down the channel to inform the application that the barcode decoder had just decoded a valid barcode. (Or, POWER_FAIL, MOTOR_AT_LIMIT, etc.) I like using FSM's in my code. User interfaces are nothing but *big* FSMs (often containing nested FSM's). It seems to make things easier to understand and modify. > Perhaps unusually, I think the code looks better in VHDL. You have > constructs like "if debounce[0] == '0' and debounce[1] == '0' and ...", > which are imperative, more descriptive than an abstract logic function is. > VHDL lets you do whatever you want with bits or vectors, whereas processors > can't construct "ifs" on a bitwise basis (not without a *lot* more code). Understood. Like me checking for "a single column" detected. Some things end up just being idioms that you hope folks will understand :< > Having typed this, maybe I'll paste it in as comment... :-p
From: Jan Panteltje on 22 May 2010 06:26
On a sunny day (Sat, 22 May 2010 00:49:31 -0700) it happened D Yuniskis <not.going.to.be(a)seen.com> wrote in <ht81uf$koo$1(a)speranza.aioe.org>: Use clear variable names, and also labels that say what is happening. get_rx_char: ; test_serial_port_interrupt btfss PIR1, RCIF ; test if serial port interrupt goto int_end ; have serial char in RCREG ; test if RS232 streaming to UDP movlw MODE_STREAM_RS232_TO_UDP cpfseq mode goto int8_no_streaming ; stream bcf flags2, TIMEOUT_FLAG bcf flags2, ALL_SEND_FLAG ; To be able to get some speed, will use 2 buffers of 106 characters each. ; Using 2 buffers for the incoming characters, and INDF1 as pointer, when one buffer is full, send_udp_data will send it, and incoming characters wil lgo to the other buffer, and vice versa. ; This way there is about 106 characters time, or ; 115200 Bd at 1 start, 1 stop, 8 data bits is 11520 characters / second, = 86.8 us / character, 106 charactes takes 9.2 mS this is the time we have to send the UDP packet. ; character to transmit buffer movfw RCREG movwf POSTINC1 incf transmit_buffer_count ; test if buffer 1 full movlw D'106' cpfseq transmit_buffer_count goto test_buffer_2_full ; buffer 1 full, ; signal to main to send buffer bsf flags2, SEND_BUFFER_1_FLAG ; wait for next character goto int_end_clr ; pointer now points to buffer 2, is RAM at 0x100 + 43 + 106 test_buffer_2_full: movlw D'212' cpfseq transmit_buffer_count ; wait for next character goto int_end_clr ; buffer 2 full ; signal to main to send buffer 2 bsf flags2, SEND_BUFFER_2_FLAG ; reset the pointer to point to buffer 1 again, should have been send by now lfsr FSR1, (0x100+D'43') ; clear the byte counter clrf transmit_buffer_count ; wait for next character goto int_end_clr int8_no_streaming: |