Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: D Yuniskis on 21 May 2010 13:47 Hi Tim, Tim Williams wrote: > "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message > news:ht5c6n$mf$1(a)speranza.aioe.org... >> I just looked at an old Z180 project that I did. Almost 9MB of >> sources. Looks like it compiled to about 200K. So, that would >> be 4.5MB/100KB code (roughly in line with my shirtsleeve estimate >> above). > > Hmm, I've got a 70k .asm file (x86, for MASM) which compiles to I think 9k > code (plus a few large arrays). Only a ratio of 7? Gee, now I look lazy at > commenting... > > > ; > ; Multiplies a fixed-point DWORD (16.16 format) by a fraction (0.16). > ; Input: on stack (DWORD, WORD) > ; Output: DX:AX = DWORD product. > ; > fixedByFrac PROC near USES bx cx si di fixed:dword, frac:word > mov di,wpr fixed+2 > mov ax,wpr fixed > mov bx,frac > xor si,si > test bx,bx ; get fraction sign > jns @F > > Ehh, looks easy enough... maybe I just read asm better? :-p It's not a question of how *you* read the code but how some poor Joe following you will read the code! :> I write lots of commentary in my code. I'm typically building "things" (not "doing math") so I need to explain why the code is doing what it is doing. And, why things that look like potential problems aren't. Or, identifying problems that *could* occur but might not be normally considered. 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. By my count (assembled in my head), this is about 70 bytes of code. The "source" is about 3500 (i.e., 50:1 instead of the 45:1 I mentioned above). -----------------8<--------------------8<------------------- Page ;The keypad handler may be viewed as a small finite state machine. This ;finite state machine implements the key debouncing functions for the ;keypad handler. ; ;Essentially, there are 3 states in the FSM model: ; ;The 'IDLE' state indicates that there is currently no keypad activity. ;In this state, all keys are released. When a key closure is detected, ;the FSM moves to an active keypad state. ; ;There are 2 active keypad states. These two states differ by the type ;of activity detected in the keypad. If one and only one key closure ;has been detected, the key number is placed in the key buffer. But, ;if two or more concurrent key closures have been detected, the key ;number is not placed in the key buffer. In either case, a ;'STUCK_KEY_TIMER' is activated to identify any key closures which ;might remain active for an excessive length of time which could ;indicate a failure in the keypad (e.g., shorted). ; ;In the 'KEY DOWN' state, the keypad is monitored for the removal of all ;key closures at which point the 'KEY RELEASED' state is entered and the ;handler begins a releasing edge debounce using the 'DEBOUNCE_TIMER'. ;If the keypad remains active (one or more key closures) long enough for ;the STUCK_KEY_TIMER to timeout, a 'STUCK KEY' event is generated and ;the 'KEY DOWN' state is reentered. ; ;In the 'KEY RELEASED' state, any key closures detected result in the ;'KEY DOWN' state being reentered. If the keypad remains inactive (no ;key closures) long enough for the DEBOUNCE_TIMER to timeout, the ;process returns to the 'IDLE' state. ; ;The Finite State Machine is modeled below: [I've removed this ASCII art as it would just end up mangled] Page KYHNDL: MARK ;Begin keypad IDLE state CALL KYPDCK ;Check to see if any key closures RET Z ;No key closures have been detected LD E,A ;Column data of row detected as first key closure DEC A ;Set bits to right of rightmost column detected AND E ;Any columns left of rightmost detected? JR NZ,TWOKEY ;Two key closures detected in same keypad row DEC B ;Set Z iff first key was detected in last row! LD D,B ;Row number of first closure [0, NMKYRW-1] CALL NZ,KYPDLP ;Check closure in another row if not in last JR NZ,TWOKEY ;Two key closures detected in different rows LD A,D ;Row number of sole closure [0, NMKYRW-1] LD B,NMKYRW ;Number of rows in the keypad SUB B ;R.A = row number of detected key - NMKYRW ONKYLP: ADD A,B ;Accumulate keynumber as (Column*NMKYRW+Row) RR E ;Advance to next column to the left JR NC,ONKYLP ;Not this column, try again. INC A ;(Column*NMKYRW+Row)+1 [1,NMKYCL*NMKYRW] CALL PUTKEY ;Append character to keypad buffer TWOKEY: LOAD STUCK_KEY_TIMER 15 SEC ;Setup stuck key timer and MARK CALL KYPDCK ;Check if any key still down JR Z,NOTKEY ;All keys released WAIT STUCK_KEY_TIMER ;A key is down, wait on stuck key timer LD A,STKKEY ;Flag indicating stuck key CALL PUTKEY ;Signal stuck key error JR TWOKEY ;Wait for stuck key condition to abate NOTKEY: LOAD DEBOUNCE_TIMER 50 MSEC ;Setup debounce timer and MARK CALL KYPDCK ;Verify still no key closure JR NZ,TWOKEY ;Key has bounced closed -- too bad WAIT DEBOUNCE_TIMER ;Still no closure, wait on timer JR KYHNDL ;Timer expired, keypad once again idle
From: D Yuniskis on 21 May 2010 14:03 Hi Dimiter, Didi wrote: > On May 21, 10:26 am, D Yuniskis <not.going.to...(a)seen.com> wrote: >> ... >> But, if you think about it, it is not difficult to have >> 10MB for a small-ish assembly language program. Assume a line >> of code generates 1.5 bytes (most generate at least *one* >> byte of code :> ). Most ASM opcodes are 3 or 4 chars. >> Put a tab on each side of it gives us 5 or 6. Put some >> arguments after it (register list, symbolic address of an >> operand, etc.) probably adds at least 10 chars. One or more >> tabs out to a "comment column" followed by 30 or 40 characters >> of commentary (?) I.e., it's easy to have 50 characters >> on that line for that 1.5 bytes of generated code. > > Hi Don, > my average is about 34 characters per line over the years, Yes, but those are just "lines". And, not every line generates a byte of code (or more). > http://tgi-sci.com/dsv/scnt3.gif :-). I write comments on > every line, headers etc., but there are null lines to > compensate for that, I guess (a sort of typical largish > source file is http://tgi-sci.com/vpaex/vpast1.sa . Part of > a much larger picture, of course (1 of 46 files which make > the vpa assembler(compiler?)). > >> ... >> My TCP/IP stack is over 100 files and a couple of megabytes of >> source (C with a tiny mix of ASM). > > Into how much object code does that compile? Seems comparable It depends on which options I support, how defensive I want the code to be (i.e., what attacks it will thwart), what services I want to include, etc. I can build it (actually, i have several different stacks developed over the years for various different criteria) in a lot of different ways depending on the hardware and software (OS) resources available. For example, does the NIC have support for hardware checksums? Or, do I have to do it in software? Or, skip them entirely?? Support for multiple interfaces? Packet forwarding? Routing protocols? How many sockets? Zero-copy semantics? etc. I can come up with a "usable" stack (single interface) in as little as ~60KB if I "try hard". I'm working on a rewrite for ARM Cortex to shift some priorities, yet again. :> I'll be curious to see how big it ends up and what sort of throughput I can get without lots of tweeks. > to my tcp/ip stack for dps, http://tgi-sci.com/misc/tcp.gif . > What is listed there is just for tcp, ip, udp, ppp - dns and above > stuff are elsewhere. And some helper objects which are already > moved elsewhere (memory_pool etc., turned out handy and I Ah, so John Larkin can see that "100 files" is not uncommon for a *subsystem* :> > moved them for more common usage). The object code this list > produces is about 230k (for power, but it is written only for > power, no backwards 68k compatibility, at least not without > some work). > Would be an interesting comparison between toolchains and > languages, I guess. I find it hard to compare things between projects because the design criteria change so much. So, I'm never really comparing apples to apples. How much should I tweek the cost of A to reflect feature X which is present in B but not A? etc. All I know is it *always* fits :> (cuz it *has* to!) :>
From: D Yuniskis on 21 May 2010 14:05 Hi Phil, Phil Hobbs wrote: >>> For a lean, poor man's "GUI", consider using a manu system >>> atop curses. *Very* fast (even over a serial link!) and >>> has all the "feel" of a GUI without the G. > > Curses is well named--it _almost_ does what you want, but never quite. Aw, c'mon... that's not fair! :> If you get the termcaps correct (!), it should behave quite well. (avoid the lower right corner, etc.) I think it is slick as snot! Some of the implementations have pretty lame optimizations. But, I've seen some that really had me scratching my head: "How did it know it could *do* that??"
From: D Yuniskis on 21 May 2010 14:42 Hi Joel, Joel Koltner wrote: > "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message > news:ht6cl3$jc8$1(a)speranza.aioe.org... >> I don't understand the false security that comes from >> putting information like that in a "name" for an object. >> E.g., I likewise don't understand "hungarian notation" >> for naming variables. > > I think there was a certain time period when software was getting pretty > big and complex but the tools hadn't caught up yet when hungarian > notation saved enough time in having to look up, "ok, now what type of > object is this again?" could -- for some people -- outweigh the minor > hassle of using it in the first place... although I never personally > felt the benefit was enough to bother. Keep modules short and sweet -- so the scope of the name is severely limited -- and you can just "page up" to the declaration (or pull up the .h). I found it was a real PITA to maintain. Change the underlying data type and now you have to go through and change the name itself. I like names like theMinuend and theSubtrahend (if you catch my drift) > These days development tools have so much "intellisense" built-in that I > don't think there's much point anymore and (happily) you do see less and > less of it. And to a certain extent, if you choose your variable and > method names descriptively and write the interfaces well, people > shouldn't have to worry about the exact type of your object anyway -- if > you have a variable that's of type, e.g., "EmployeeName," it should be > safe to assume it can act like a string. I read code in two passes (figuratively). First, I want to get a feel for what the code is trying to do. *Then*, I want to see how it is doing it. Unadorned names tie the code "down" instead of letting it be read abstractly. Why not call things "variable1" and "variable2", etc. :< >> I'm sure glad my parents didn't name me: boy_son_eldest_Don! > > I try to convine people that if you have a schematic sitting in, e.g., > c:\Schematics\Top Secret Projects\NSA Spy Satellite\RF Transmitter, it's > kinda silly ot make the file name "Top Secret NSA Spy Satellite RF > Transmitter Schematic.SCH," but not everyone buys into this. (Granted, > I'm exaggerating, but you get the idea -- I really do see a lot of > "Project Name Functional Name Schematic.SCH" files...) Understood. My biggest peeve is music files. Too many music players sort based on name instead of the tags in the files. So, you end up with tunes played in alphabetic order instead of "track order". As a result, you have to name your files: 01 - Open Up Wide.mp3 <shrug> At least until folks get around to making smarter players and interfaces to them. I likewise complain about having a "file type" as part of a file name. It's hungarian notation *backwards* -- does that make it *better*?? :<
From: Phil Hobbs on 21 May 2010 14:49
On 5/21/2010 12:40 PM, D Yuniskis 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. > > I don't understand the false security that comes from > putting information like that in a "name" for an object. > E.g., I likewise don't understand "hungarian notation" > for naming variables. > > I'm sure glad my parents didn't name me: boy_son_eldest_Don! > > I see this sort of behavior in many places. People seem > afraid to "let go" of data and trust something else to > keep it handy (and safe!) for them! > > I see people building "databases" in spreadsheets simply > because they fear "not seeing ALL the data". (and I mean > *huge* spreadsheets -- hundreds of columns, thousands of > rows) When shown how to get the same results with > a database, they cringe because "it's magic" -- the numbers > "just appear" instead of being displayed in front of them > (static) all the time. > > I ask them, "How does seeing all of these numbers help > you understand them? Do you know, for a fact, that *this* > number HERE is correct? Are you sure the formula in this > cell hasn't been changed in JUST this cell? Do you > regularly examine the formulae? > > (glassy-eyed stare) > > Computers are good for two things: doing lots of things fast > and remembering stuff. They've got me beat on both counts > and I'd be foolish to try to compete with them :> We're all dead in the long run. ;) I do some work for a small company that uses the sequential system. The problem I run into is in trying to change anything--you have to dig through all sorts of irrelevant things to find the next resistor value up. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal ElectroOptical Innovations 55 Orchard Rd Briarcliff Manor NY 10510 845-480-2058 hobbs at electrooptical dot net http://electrooptical.net |