27 Apr
2006
27 Apr
'06
9:23 a.m.
When I was
developing Z80-based products, an ongoing *battle*
was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
The octal camp claimed the Z80 was an "octal machine" (oh, really?)
and, for "proof", showed how so many of the opcodes could be
committed to memory just my noting the source & destination
register "codes" and packing them into an octal representation:
xx xxx xxx (of course, I wonder how well their argument would
stand up if Zilog had opted to encode the register fields
as: xs dds dsx?? :> )
It would appear that the *nuts* was implied: by (oh, really?)m Quotes
around "proof", suggestion that the opcode encoding is randomly
organized etc.
Octal? Hex? Just give me a symbolic
debugger and let *it*
keep track of these minutae...
Like your mouse below, symbolic debuggers didn't exist for many
of us in the mid 70's. I don't
imagine those hobbyists *prefer* using hex/decimal
keypads and 7 segment displays to write their code?
Well... I think they *DID* prefer using keypads and displays - If
they hadn't, they would not have used them. In my case: I could
have dropped out of school and used my tuition money to buy a
development system, but I preferred to do something within my
means. I could have tossed the 8080 and taken up fly-fishing as
a hoppy, but I preferred make do with what was available to me.
For me, the keypad/display was "the way to go" at the time. You're
missing the point: it was a waste of time to invest
all that energy in half-*ssed tools instead of moving to
more "current" technology. If your goal is to bring a product
to market (NOT to deal with hobbyists), you devote your
resources to things that can measurably improve your
productivity. Throwing resources (software and hardware
development time and money) on tools that don't make a
dramatic increase in your productivity is just foolish.
My points:
1) for many, Octal was natural - just because you consider it
half-donkeyed doesn't "make it so".
2) Had you been from the "octal camp", you would now be
stating how it wasn't suitable to put time and energy into
dealing with the half-assed hex crap. 3) Many of us started during this time period and
made do with
what we had (and learned a lot more because of it) - A lot of
us went on to productive lifetime careers in the business - so
there must have been some benefit to our approach.
Sure. All of the boards, code, cabinetry, etc. that I made
for home projects relied on techniques and materials that
I could purchase and manipulate on a hobbyist's budget.
But, I didn't refrain from using injected molded plastic
parts in designs at work! And, I didn't waste their time
engaging in discussions about whether it was best to fabricate
cases in wood or lexan (two materials I could easily work with
at home). The "wood camp" and "lexan camp" weren't appropriate
to the WORK camp!
4) I would argue that in the mid-70's, our
approach was in line
with "current" microprocessor technology, and high-end
development systems were "cutting edge" technology - I know
a lotta little (at the time) companies who worked near the
bottom.
5) Learning instruction set encodings, and finding ways to
simplify that and speed up our mental "access time" to it
DID dramatically improve our productivity.
Sure. But (aside from nostalgia), I assume only when you *have* to.
If I've got to maintain something written for a 2A03, I'll grumble
and cuss and push my rates up since I know I'll be *stuck* working
in ASM. If I have to write a BSP for a new ARM, I'll grumble a
little bit but I know there WILL be an end in sight and I (typically)
won't be stuck writing in ASM "forever". But, if I have to write a
protocol stack, I'm not even going to *think* about doing anything
more than, perhaps, checksum calculations in ASM.
Like writing code in assembler when you could
just as readily
use a HLL.
I'm not even going to go there (I still write a substantial amount of
assembly language). I never saw it as a huge waste of
"resources" - In the early
You didn't rewrite ("re-bug")
WORKING development tools
in a production environment to add these "features".
If you've got an assembler, linkage editor, etc. that all
WORK but produce HEX listings, why rewrite them to spit out
listings in split octal? Including addresses (of opcodes,
arguments, link maps, etc.) Are you going to gain that much
in terms of productivity to offset the time spent doing this?
And the bugs that get introduced in the process? > Clearly
the debate can rage on forever - If you like hex, and
> consider it the "only game in town", then thats OK by me. I
> happen to see advantages to both viewpoints.
Nuff said - lets just agree to disagree.