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