vic plichota


Biography has not been added


's contributions
    • This article was badly flawed in 2006, badly flawed again in 2010, and /still/ badly flawed in 2012 (almost 2013); why on earth did it get re-issued?

    • It's unfortunate that Ada doesn't have the huge variety of free tools that C boasts. Really the *only* reason that C became so ubiquitous, was it's free distribution... Wrt DbC, I feel compelled to point out that FORTH programmers are habituated to DbC methodology -- albeit in a somewhat limited sense when compared to Ada.

    • I couldn't agree more. When the developers are dedicated to a mandate for high quality, they produce high quality software, regardless of the toolchain.

    • (This forum does not allow chevron chars, so I am forced to use [left] instead.) Here's another tricky C compiler nuance: when trying to do a 32-bit LEFT-shift of a 1-bit quantity (or any other constant) on a 16-bit target CPU, unsigned long bit32; int leftshiftamount; bit32 = (1 [leftleft] leftshiftamount); does not work. Meanwhile, bit32 = (1L [leftleft] leftshiftamount); or bit32 = (1UL [leftleft] leftshiftamount); DOES work; interesting subtlety of the compiler cue, considering that it already bloody well knows that the target operand is a 'long'. Weirder still, the problem was masked by the fact that 32-bit RIGHT-shifts worked fine! go figger... I wouldn't be surprised if 32-bit targets compile differently. All the more reason to ALWAYS use the explicit ANSI-99 typing conventions for vars, but this was a simple constant -- any requirement for explicit typing was NOT not obvious. I'll say it again: I pity folks who code and try to debug HLLs without knowing their assembler, they must go through absolute hell.

    • Eschew obfuscation: better to write two un-ambiguous lines of code, than one line that can't be specified. Every time I encounter C code that's difficult to understand, the programmer was being cute, tricky, and 'elegant' with the syntax -- EVERY time. Enough!

    • Don't forget to add a *plastic* sliderule to the kit -- they float. :-)

    • Great comments. I don't write 'loops'; I prefer state-machines supported by interrupt-balancing... This requires reading the datasheets and investing in testing and stressing proof-of-concept prototypes.

    • Excellent article. With a bit of extra programming, you can also sometimes use a 'companion' microcontroller instead of a dedicated logic analyzer.

    • How about Intel's iAPX432, the Ada machine? P.S. the 1802 was my first micro; the instuction set was so simple, you could 'assemble' machine opcodes in your head... :-)

    • The user-interface (e.g. on phones and tablets); it never seems to do what I expect, and doesn't seem to offer any options for 'tuning' it to fit my style... As far as I know, it forces me to re-learn everything that I've previously learned wrt using GUIs, and many operations simply make no sense -- different for the mere sake of being different, rather than offering any obvious improvement. Again I must ask: am I missing some simple trick, or am I hopelessly stuck in an anciant "double-click" paradigm??? thanks, - vic