Is this a true statement?
David C. Ullrich
ullrich at math.okstate.edu
Sun Jun 24 09:22:46 EDT 2001
On 23 Jun 2001 18:42:20 GMT, David LeBlanc <whisper at oz.nospamnet>
wrote:
>In article <3b34939b.410758 at nntp.sprynet.com>, ullrich at math.okstate.edu
>says...
>> On Fri, 22 Jun 2001 12:47:23 -0400 (EDT), "Steven D. Majewski"
>> <sdm7g at Virginia.EDU> wrote:
>>
[...]
>>
>The reason why you can't write a device driver in pure Python is simple:
>a device driver requires the ability to read to and write from specific
>pre-determined locations in the processor's memory and/or I/O space.
Yes, a device driver has to do this. But I don't see why a program
that _writes_ a device driver has to do these things.
>It would be possible, if best performance where not required, to extend
>Python with C or ASM (and possibly C++, but not without some dificulty:
>passing "this"pointers gets in the way when crossing memory management
>and/or procsss thresholds. This is why you can't write, for example, a
>multi-tasking OS in pure C++.) which would permit inserting driver start
>addresses into trap (interrupt) vectors, reading and writing device
>registers or calling device firmware entry points at specific locations
>etc.
>
>Such systems have been written and probably do continue to exist,
>particularly along the lines of the higher level parts of the device
>driver being written in an HL language (even <shudder> BASIC) and the
>fast slippery parts written in LL language. I've done as much with
>Smalltalk on a PC.
>
>Of course, with enough glue and the right scaffold, one could glue up
>enough toothpicks to reach the moon.
>
>Dave LeBlanc
David C. Ullrich
*********************
"Sometimes you can have access violations all the
time and the program still works." (Michael Caracena,
comp.lang.pascal.delphi.misc 5/1/01)
More information about the Python-list
mailing list