• LCrawford (unregistered)

    Ahh yes, the 70's and the feeling of being the frist developer to encounter these coding situations. The ultimate Not Invented Here library of routines.

  • Prime Mover (unregistered)

    Bitwise or no bitwise, not sure whether exponentiation could ever be the way to go here. Exponentiation can be expensive. Because I don't have the manual in front of me (Bob bogarted it), I can't check this, but I wouldn't risk implementing something which may compromise response time.

  • (nodebb)

    Bits wise, byte foolish!

  • S's cat (unregistered)

    Doesn't BITON have a bug? If A is out of range it sets the value as false, but then falls through to the IF statement with C undefined.

  • akozakie (unregistered)

    Say what you want, but I'd LOVE to support this. So what if the implementation sucks. It works, it's clear and readable, intent is obvious... incredibly easy to fix or optimize anything as needed. Give me that over any "mostly correct, fast and efficient code" with a mix of premature optimization and stack overflow ^C^V, with no comments, nonexistent documentation, no consistency in names and "only some seemingly trivial bugs"...

  • Anon E. Mouse (unregistered)

    The really funny (smell, not ha ha) thing is that the ACM had an entire referred journal devoted to these things. You could go back to the early volumes (have to love open stack libraries) and find proven algos for this kind of stuff. Or you could go to Knuth's 3 volume set.

    The one thing you didn't do was hand code it blind. As a EE/CS student in the late 70s/early 80s, my Profs would have - rightfully - roasted me for this. If you could cite a source, it was OK. But off the cuff. Nope.

  • Hasseman (unregistered)

    HP3000. Software created 1972 was guaranteed to still work 2010. Maybe not the sexiest machines but very stable. We had 380 days of uptime once. HP3000, Vax11/750 and DataGeneral Eclipse. Good old days.

  • Duston (unregistered)

    I learned BASIC on an HP3000 (1978). My fond memory was that it didn't have subscripted strings, so a subroutine to sort a bunch of strings alphabetically was for the advanced students. And the other fond memory was that most of the terminals used acoustically coupled modems, so if you stood up too quickly and made your chair squeak, you'd knock a room full of terminals off line. Good times.

  • The incredible Holk (unregistered)

    Move those repeated case blocks to a separate function and the code becomes almost sane.

  • (nodebb) in reply to S's cat

    Yeah, buggy. If A doesn't match, C will be uninitialized which means it's an unpredictable value. In TIO, the uninitialized value of C depended on the last run:

    uninitialized first: random value in C, resulted in TRUE result: https://tio.run/##K0gsTk7M0U0rSP7/Pyk1PTOPi7O8KLMkVUPdIzUnJ19HITy/KCdFUV3Tmis1L0Xv/38A

    intialized first: zero in C, resulted in runtime error: https://tio.run/##K0gsTk7M0U0rSP7/Pyk1PTOPi7O8KLMkVUPdIzUnJ19HITy/KCdFUV3Tmis1L0Xv/38A

  • Couple Things (unregistered)

    Change all the INTEGER types to WORD and you'll actually have code that works.

    ... ok just the one thing.

  • The other thing (unregistered)

    Remembered the other thing: I don't like that the MSB is referenced as bit 0.

  • Zygo (unregistered)

    Exponentiation in the 70's was amazingly expensive, even when not counting the floating-point-to-int type conversions needed.

    So of course we would precompute that in a table to look up at run time.

    Oh. Right.

    For the '90s EE/CS student, off the cuff stuff was OK, you'd "only" have to give a correctness proof to justify it. A reference to someone else's published proof then becomes valuable to save work.

    It's amazing how much code we rely on every day is based on someone's grad thesis paper.

  • Randal L. Schwartz (google)

    My first substantial coding was on the predecessor to the 3000, the HP2000, in TimeShare Basic. The 2000 was actually a pair of HP2100 machines: one for I/O and one for core compute. Dialup 110 baud ASR-33 uppercase-only TTY, with paper-tape storage. Sat in the "computer closet" for many hours a day during my Junior high and high school years. Probably why I have a ringing in my ears now.

  • Bart (unregistered) in reply to Prime Mover

    It's very unlikely that this version of Pascal supported integer exponentiation out of the box. It would possibly have an exp() function, using reals.

  • The Shadow Knows (unregistered)
    Comment held for moderation.
  • (nodebb)

    Could it be that at the time the code was written, or the system it was written on, or another system it might have to run on, didn't support bitwise operators? That's the most likely explanation.

  • (nodebb) in reply to The incredible Holk

    Move those repeated case blocks to a separate function and the code becomes almost sane.

    I'm thinking an array containing the required power of two and indexed by the bit number.

    Addendum 2021-09-15 05:14: It reminds me of a Stack Overflow question "what's the fastest way to calculate the nth Fibonacci number". My answer was to put the first 96 in an array (assuming the required answer is returned as a 64 bit int) and just do a look up.

  • (nodebb)

    The thing that really weirds me out is the choice of ordering the bits left-to-right, rather than by power of two like pretty much everyone does.

  • Foo AKA Fooo (unregistered)

    So we're not commenting on turning an O(1) operation into O(n^2) (LAND)? Sure, one order of magnitude is par for submissions here, but two?

    Or the unnecessary SETBITON call when BITON is already true?

    Using a REPEAT loop instead of FOR? (So much for readability?)

    The good old "IF .. THEN ... True ELSE ... False" pattern?

    At least the "OTHERWISE" bug in BITON (which stems from Pascal not having a RETURN statement) has been mentioned, as well as a problem with the high bit (assuming INTEGER is 16 bit). (WORD is not a standard Pascal type; if this compiler doesn't have it, the high bit needs special cases, depending on whether it's two's complement or other representation, which are considerations you normally don't want to see in Pascal code.)

    No, sorry, there's nothing good about this code.

  • Clubs21ids (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Medinoc

    The HP3000 was a big-endian machine. So the sign bit was bit 0. and the address of an integer was the address of its most significant byte (assuming it had byte-addressable memory) Like the Motorola 68000s. Like the Sun Sparc. Like the fundamental networking protocols.

  • (nodebb)

    NOT even close... DEC minicomputers had multiple timesharing operating systems release in 1968 (and pre-release was avail a bit earlier)

  • The Shadow Knows (unregistered) in reply to Jeremy Pereira

    Reminds me of a test question at an interview long ago - basically write a program that prints the result of [complex equation] and my solution was something like PRINT 1234546. I'd mentally solved the equation and was ready to argue that they needed to have better specs for their assignments.

  • ramson (unregistered)
    Comment held for moderation.
  • Stan Sieler (unregistered)
    Comment held for moderation.
  • Stan Sieler (unregistered)
    Comment held for moderation.
  • Arto Ahlstedt (unregistered)

    I needed byte-wide XOR and had to resort to building a (very straightforward so it was 15 min study and worked on first try) SPL (HP 3000's Systems Programming Language) function and link my Pascal program to it. So, the thing even had a low-level somewhat structured language!

Leave a comment on “Wise About Bits”

Log In or post as a guest

Replying to comment #532777:

« Return to Article