sc...@slp53.sl.home (Scott Lurndal) writes:
> Victor Bazarov <v.ba...@comcast.invalid> writes:
>>On 1/10/2012 12:14 PM, Scott Lurndal wrote:
>>> "Alf P. Steinbach"<
alf.p.stein...@gmail.com> writes:
>>>> On 10.01.2012 09:30, Nick Keighley wrote:
>>>>>
>>>>> scarey thought. There are people writing device drivers that don't
>>>>> know hex?
>>>>
>>>> Why not use octal? Saves you typing an "x". After all, the creators of C
>>>> were quite happy with octal for expressing low level bit patterns.
>>>>
>>>>
>>>
>>> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
>>>
>>> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
>>> hailed.
>>
>>Are you saying that 040 is more difficult to read than 0x20? Just
>>checking...
>
> No, I'm saying that I can look at 0x12345678 and visually determine which
> bits are set in which bytes. It's much more complicated for 02215053170.
Whereas for me it's the opposite.
But wait -- what you have memorized, to decode the hex, is a superset of
what I know to decode the octal. How, then, can it be "much more
complicated" to decode the octal? It involves decoding more digits, so
I can't argue against "slightly more work" or something like that. But
the principles are identical, and the tables needed in memory are a
subset of the hex tables.
> On the other hand, when I was writing PAL-D code for the pdp8, 4 digit octal
> numbers worked just fine due to the 12-bit word.
Yep, that's where I learned to do octal. Actually toggling in the RIM
loader is where I learned to do octal.