On 11/05/2018 14:24, Chris Angelico wrote:
On Fri, May 11, 2018 at 9:09 PM, bartc <b...@freeuk.com> wrote:
when 101'11010'000'B then ...
Try /that/ in hex /or/ octal.)
I've no idea what this is supposed to mean, or why you have groups of
three, five, and three. Looks like a possible bug to me. I'm sure it
isn't, of course, since you're one of those perfect programmers who
simply doesn't _make_ errors, but if it were my code, I would be
worried that it isn't correct somewhere.
The data-sheet for the 8087 numeric co-processor displays instructions
of the two-byte opcodes in formats like this (high to low bits):
[escape 1 0 1] [1 1 0 1 0 ST(i)]
'escape' is the 5-bit sequence 11011. ST(i) is a 3-bit register code. So
considered as a one 16-bit value, it's divided into groups of 5:3:5:3.
The escape sequence has already been detected, and the middle two groups
have been isolated by masking with 111'11111'000B.
So it is checking for combinations of those middle 3:5 groups of bits in
a way that exactly matches how it's presented in the data sheet. And
this instruction encoding is still used in current AMD/Intel x64 processors.
The xxxxx-101-11010-xxx pattern corresponds to the FST ST(0) to ST(i)
instruction:
when 101'11010'000B then
genstr("fst ")
genstr(strfreg(freg))
It's not a bug. Just a good example of the use of binary where hex or
octal doesn't cut it because the grouping isn't purely in threes or fours.
(I understand that binary literals were added to Python from version
2.6. The question is why it took so long. They are not a heavyweight
feature.)
Cool. So what's the native integer size for the real world? Use that
as your primary data type.
Oh, can't decide how many digits? That's a pity.
What's this got to do with octal? Because many languages impose a limit
on the widths of numeric types, that somehow makes it OK to implement
octal using leading zeros? Just to catch people out because octal is
used so rarely.
Go get a time machine. Spend some time in the 1980s. See what kinds of
programming people were doing. HINT: It wasn't web app development.
I was doing lots of development in the 1980s. I just didn't use C.
Yeah, which is why your personal pet language has approximately one
user. The more things you change when you create a new language, the
more likely that it'll be utterly useless to anyone but yourself.
Consistency is a lot more important than many people give it credit for.
That's why 0100 is sixty four in Python 2, and an error in Python 3?
Instead of being one hundred in both, as common sense would have dictated.
And, for that matter, one hundred in any of my languages, some of which
did have more than one user.
BTW here is one C-ism that /didn't/ make it into Python 1:
print (0xE-1)
This prints 13 (0xE is 14, minus 1). But it would be an error in
conforming C compilers:
printf("%d", 0xE-1);
"error: invalid suffix "-1" on integer constant"
Perhaps consistency isn't always as important as you say, not for
something which is crazily stupid.
At least 0xE-1 generates an error (on some compilers; on others, only
years later when you switch compiler). 0100, if not intended as octal,
is an undetectable error in C and Python 2.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
