is None or == None ?
in [Python]
|
Prev: 2to3 on Mac - unknown encoding: mbcs
Next: safely returning objects from a Process to the parent through aQueue()
From: Rhodri James on 9 Nov 2009 20:02 On Sun, 08 Nov 2009 19:45:31 -0000, Terry Reedy <tjreedy(a)udel.edu> wrote: > I believe the use of tagged pointers has been considered and so far > rejected by the CPython developers. And no one else that I know of has > developed a fork for that. It would seem more feasible with 64 bit > pointers where there seem to be spare bits. But CPython will have to > support 32 bit machines for several years. I've seen that mistake made twice (IBM 370 architecture (probably 360 too, I'm too young to have used it) and ARM2/ARM3). I'd rather not see it a third time, thank you. -- Rhodri James *-* Wildebeest Herder to the Masses
From: Grant Edwards on 10 Nov 2009 10:46 On 2009-11-10, Rhodri James <rhodri(a)wildebst.demon.co.uk> wrote: > On Sun, 08 Nov 2009 19:45:31 -0000, Terry Reedy <tjreedy(a)udel.edu> wrote: > >> I believe the use of tagged pointers has been considered and so far >> rejected by the CPython developers. And no one else that I know of has >> developed a fork for that. It would seem more feasible with 64 bit >> pointers where there seem to be spare bits. But CPython will have to >> support 32 bit machines for several years. > > I've seen that mistake made twice (IBM 370 architecture (probably 360 too, > I'm too young to have used it) and ARM2/ARM3). I'd rather not see it a > third time, thank you. MacOS applications made the same mistake on the 68K. They reserved the high-end bits in a 32-bit pointer and used them to contain meta-information. After all, those bits were "extra" -- nobody could ever hope to actually address more than 4MB of memory, right? Heck, those address lines weren't even brought out of the CPU package. Guess what happened? It wasn't the decades-long global debacle that was the MS-DOS memory model, but it did cause problems when CPUs came out that implemented those address lines and RAM became cheap enough that people needed to use them. -- Grant Edwards grante Yow! Either CONFESS now or at we go to "PEOPLE'S COURT"!! visi.com
From: Marco Mariani on 10 Nov 2009 10:56 Grant Edwards wrote: > MacOS applications made the same mistake on the 68K. And and awful lot of the Amiga software, with the same 24/32 bit CPU. I did it too, every pointer came with 8 free bits so why not use them? > It wasn't the decades-long global debacle that was the MS-DOS > memory model, but it did cause problems when CPUs came out that > implemented those address lines and RAM became cheap enough > that people needed to use them. I suppose that's the reason many games didn't work on the 68020+
From: Grant Edwards on 10 Nov 2009 11:46 On 2009-11-10, Marco Mariani <marco(a)sferacarta.com> wrote: > Grant Edwards wrote: > >> MacOS applications made the same mistake on the 68K. > And and awful lot of the Amiga software, with the same 24/32 > bit CPU. > > I did it too, every pointer came with 8 free bits so why not > use them? TANSTAFB ;) I should probably add that MacOS itself used the same trick until system 7. >> It wasn't the decades-long global debacle that was the MS-DOS >> memory model, but it did cause problems when CPUs came out that >> implemented those address lines and RAM became cheap enough >> that people needed to use them. > > I suppose that's the reason many games didn't work on the 68020+ Probably. IIRC, it took a while for some vendors to come out with "32-bit clean" versions of products. http://en.wikipedia.org/wiki/Mac_OS_memory_management#32-bit_clean -- Grant Edwards grante Yow! I know how to do at SPECIAL EFFECTS!! visi.com
From: Steven D'Aprano on 10 Nov 2009 13:55
On Tue, 10 Nov 2009 15:46:10 +0000, Grant Edwards wrote: > On 2009-11-10, Rhodri James <rhodri(a)wildebst.demon.co.uk> wrote: >> On Sun, 08 Nov 2009 19:45:31 -0000, Terry Reedy <tjreedy(a)udel.edu> >> wrote: >> >>> I believe the use of tagged pointers has been considered and so far >>> rejected by the CPython developers. And no one else that I know of has >>> developed a fork for that. It would seem more feasible with 64 bit >>> pointers where there seem to be spare bits. But CPython will have to >>> support 32 bit machines for several years. >> >> I've seen that mistake made twice (IBM 370 architecture (probably 360 >> too, I'm too young to have used it) and ARM2/ARM3). I'd rather not see >> it a third time, thank you. > > MacOS applications made the same mistake on the 68K. They reserved the > high-end bits in a 32-bit pointer and used them to contain > meta-information. Obviously that was their mistake. They should have used the low-end bits for the metadata, instead of the more valuable high-end. High-end-is-always-better-right?-ly y'rs, -- Steven |