Software bloat (Larkin was right)
in [Design]
|
Prev: OrCad/ question
Next: Capture hierarchy
From: D Yuniskis on 23 May 2010 03:06 Hi Dimiter, Didi wrote: > On May 21, 9:03 pm, D Yuniskis <not.going.to...(a)seen.com> wrote: >>>> ... >>>> 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". > > Of course we have no chance to compare apples to apples, but > perhaps we could get some feeling. I was more after a > "fullblown" thing, the directory list I posted does it "all", > tcp & udp checksum, crc16 & 32 (for ppp), defaults to a 512 > simultaneous connections (never used up so far :-) ), generally > you get a stack a "normal" OS would expect. "Zero copy" is never I don't ever configure a stack like you would encounter in a desktop machine. There are always "optimizations" I can make based on the application deployment. I really don't know what the stack would look like if I tried to flesh it out as a "general purpose" stack. :< > really quite zero, but to the extent reasonable I am doing it. > Incoming tcp data will get copied once if the application > asks for it just "somewhere" in its memory space, I know of > no other sane way of doing it. Packets can also be accessed > raw, of course, but normally tcp is about having an uninterrupted > stream. Outgoing data are not copied at all if the hardware > will allow it (on the mpc5200 it does, except IIRC for tiny > packets where it was impractical to pursue). I'll send you a copy of my current stack when it's done and you can thumb through it and see how it compares (feature- and size- wise) with what you have.
From: JosephKK on 23 May 2010 08:46 On Wed, 19 May 2010 13:20:23 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: >"D Yuniskis" <not.going.to.be(a)seen.com> wrote in message >news:ht1h0t$9d$1(a)speranza.aioe.org... >> 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. > >MiniCom does this... I kinda like it; reminds me of the old Procomm Plus for >DOS. Rather early versions of turboC and turboPascal had tools like this as well. Given with tool as open source, licence free.
From: JosephKK on 23 May 2010 14:46 On Thu, 20 May 2010 19:58:07 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi John, > >John Larkin wrote: >>> You developed this in-house? Why not use something off-the-shelf? >>> (OTOH, most OTS solutions force you to do business "their way") >> >> We tested some commercial packages and didn't like them. They clearly > >Understandable. > >> didn't understand the electronics business, were slow (usually sat on > >This ^^^^^^^^^^ is true of damn near all OTS software solutions, IMO. >It *might* work for the folks who wrote it. But, probably won't >for anyone else (since no two companies do things the same way) > >> top of a general-purpose database manager, a hazard in itself) and >> often had silly per-seat-per-year license rules. >> >> I wrote the skeleton of this myself and we hired a contract guy to do >> the detail coding. The biggest part wasn't the code, it was inventing >> and documenting a new part numbering system, re-describing all the >> parts in stock (close to 5000 of them) and moving/relabeling all the >> bins. It was worth it, and now we own the source code. > >I don't believe in "part numbering systems" beyond: "How many >digits in the P/N?" (see other thread for my discussion). > >E.g., how would I even *begin* to assign part numbers to each >of the software modules I create? Software is usually kept track of with a version control system. Which may or may not be (directly) part of your development environment. > >The biggest mistake *I* made was not giving *everything* >a part number (I didn't think certain things would ever need >to be "controlled"). > >> The Brat bird-dogged the project to completion, including browbeating >> the programmer into doing good work and forcing the engineers to go >> through those 5000 part records one at a time. I was impressed.
From: D Yuniskis on 23 May 2010 15:13 Hi Joseph, JosephKK wrote: > On Thu, 20 May 2010 19:58:07 -0700, D Yuniskis <not.going.to.be(a)seen.com> > wrote: > >>> I wrote the skeleton of this myself and we hired a contract guy to do >>> the detail coding. The biggest part wasn't the code, it was inventing >>> and documenting a new part numbering system, re-describing all the >>> parts in stock (close to 5000 of them) and moving/relabeling all the >>> bins. It was worth it, and now we own the source code. >> I don't believe in "part numbering systems" beyond: "How many >> digits in the P/N?" (see other thread for my discussion). >> >> E.g., how would I even *begin* to assign part numbers to each >> of the software modules I create? > > Software is usually kept track of with a version control system. Which > may or may not be (directly) part of your development environment. Version control just tracks "versions". I.e., what changed between two consecutive -- and by extension, any *two* -- versions of a module (whether it is text or anything else). But, you need to assemble modules into complete subsystems and/or applications to have anything useful (few people "produce" source code of individual modules as their sole "product"). So, you need a way of tracking which modules (and revision thereof) were "combined" -- and *how* -- to produce a particular "program image". Then, something else that tells how that program image is massaged into/onto a medium that a processor can execute (in some domains, this is a ROM/FLASH/etc; in others, it's one or more files in a native filesystem; in still others, it's slushware; etc.) In any case, you need to be able to have a repeatable and reproducible process that defines how you got "there" from "here". And, all of the "components" in that process need to be "controlled" by some sort of document (you can't just say "get an image from engineering") So, how do you assign part numbers to software modules? Especially if you are of the belief that the part number should be *significant*? (i.e., so you can look at a P/N and figure out *algorithmically* what the module is/does)
From: JosephKK on 23 May 2010 15:27
On Sat, 22 May 2010 21:33:56 -0700, D Yuniskis <not.going.to.be(a)seen.com> wrote: >Hi Tim, > >Tim Williams wrote: >> "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message >> news:ht81uf$koo$1(a)speranza.aioe.org... >>>> -=-=-=- >>>> >>>> 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". >> >> Yup, it runs once every 16ms, called by the 1kHz global timer (which is also >> the PWM generator for analog outputs). Lots of stuff > >Yes, every "time" has some underlying granularity. >I.e., my "50 MSEC" references for DEBOUNCE_TIMER is only >guaranteed to be at least 50ms -- if the jiffy runs at 3ms, >then you can end up with 51ms (17*3), etc. > >I like coding the actual times in the code (since they >pertain to the actual technology used in the switches) >as the jiffy can change without having to rewrite the >code, etc. > >>> 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). >> >> Events aren't something I've done much with. It's quite handy, but very >> heavy handed. You can easily define KEY_DOWN, KEY_HOLD, KEY_UP, etc. events >> for each key, but where do they go? You start getting something like > >You only define events for things that are significant to your >application. And, you can route events to different *parts* >of your application (so you don't have to have "everything" >routed to one giant process. > >> Windows (or more specifically, maybe a DirectX API) where you can register >> functions with events. So you need to store more pointers, and assign all >> of them when moving to different sections, where the actions are different, >> and so on. When you need reconfigurable control that general, it can't be >> beat. >> >>> 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. >> >> Well, if you want to get technical, the whole processor is one FSM, or can >> be reduced to one (in the same way a complex control loop can be simplified > >Of course! > >> to a single transfer function). So regardless of how it's written, I'm >> doing that implicitly. But the point is if it reads that way, which it >> doesn't necessarily. :) The downside to programming state machines is, you >> need a state variable. If-then-loop constructs use other variables, program >> counter and so on as implict state variables, which saves on memory. > >Each state machine needs a "current state". It is also helpful to >keep a "stack" of previous states. And, of course, a list of event >sources. > >Here, for example, is a *part* of a FSM that collects a decimal >integer from the user: > > STATE IDLE >Case '0' thru '9' Goto GATHER Executing Firstdigit >Case CLEAR Goto IDLE Executing Reinitialize >Case ENTER Goto PREVIOUS Executing Accept >ORELSE Absorb > > STATE GATHER >Case '0' thru '9' Goto SAME Executing Accumulate >Case CLEAR Goto IDLE Executing Reinitialize >Case ENTER Goto PREVIOUS Executing Accept >ORELSE Absorb > >Firstdigit: > accumulator <- (key - '0') > goto Feedback > >Reinitialize: > accumulator <- default_value > >Feedback: > discard event > display accumulator > produce key click > discard last state > RETURN > >Accept: > blank display > make accumulator available to application > >Absorb: > discard last state > RETURN > >This is more involved than need be as it allows a "default >value" to be passed to the FSM as the "value" which is displayed >in IDLE and accepted, "as the default", if the user ENTERs >while in IDLE. Otherwise, once the user has begun typing, >the default is discarded and the digits accumulated. > >I.e., once in GATHER, we are accepting input from the user. >While we are in (or *return* to) IDLE, we are using the >"default value". > >N.B. discard last state explicitly gets rid of the "pushed" >state name which preceded this "state transition". I.e., we >don't care about the storing the history of state transitions >*within* this little FSM since they contain nothing of >interest. OTOH, the state transition that intially brought >us *into* IDLE (i.e., the equivalent of a "Call GetValue") >still lingers in the state history stack so we can "return" >to that "calling state" once the value has been ENTERed. > >Note, also, that the event that completed the FSM ("ENTER") >is propagated back to that "calling state" so it can treat >it as "value now available" (in accumulator). In each other >case, the event that initiated the state transition is >explicitly "discarded"/absorbed. > >I have several different implementations of this which >vary depending on whether I want to pass the event "code" >on to the "transition routine" (e.g., Accept, Reinitialize, >etc.) or not; whether the previous state is "pushed" >automatically or not; etc. > >Also, the encodings of each line of the table(s) varies >depending on the implementation and how I trade space for >time (this "four argument" format can encode in as few >as 4 bytes). > >A user interface is just pages of tables expressed like this. >So, you know exactly what causes the machine to move from one >state to another (testing is *really* easy!) > >And, the FSM concept is an ideal way to implement other >protocols (e.g., communication). It makes it really obvious >what are "valid" and "invalid". > >> There are cases where you don't have a better way to do it, so you use a >> state variable, or you already have something that looks like a state >> variable, so you use that. I got my real introduction to interacting FSMs in the documentation of the workings of the Motorola MC68488. A classic on how to do bus protocols with FSMs. I wish i still had a copy of that. The idea of user interface as a FSM surprised be but made immediate sense. |