Is this a true statement?

[David LeBlanc]

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:
> 
> >
> >
> >On Fri, 22 Jun 2001, David Lees wrote:
> >
> >> Not necessarily.  It might go faster if you were comparing a Python
> >> built-in operation (coded in C) with something inefficiently coded in
> >> C++.  But the statement that "Python can do everything C++" is true, but
> >> a tautology. You can substitute nearly any language; Basic, C, Algol,
> >> Lisp,... and it is still a true statement.
> >> 
> >> david lees
> >> 
> >> 
> >> MDK wrote:
> >> > 
> >> > Python can do everything C++ can do but just slower.
> >
> >Wrong, David. 
> >Turing completeness means that anything you can *COMPUTE* in one
> >language you can computer in another. Python, Lisp, C++, etc.
> >are all equivalent in that sense. 
> >
> >But you can't *DO* all of the same things in all languages -- for
> >example: you can write a device driver in a language if you can't
> >specify interrupt vectors or hardware address pointers. 
> 
> ??? I thought a device driver was just a file, hence a finite
> sequence of bytes. You can certainly use Python to write an
> arbitrary sequence of bytes to a file. No doubt it's much easier
> in C++ (or rather in typical implementations of C++?) to decide
> _what_ sequence of bytes to write to that file, but if we're
> talking about what's literally possible and impossible I don't
> see how writing a device driver can be impossible in Python.
> 
> Could well be that your distinction between what you can do
> and what you can compute makes sense, but I don't see how
> _writing_ a device driver is anything but "computation"
> (given the appropriate documentation.) Maybe I'm missing
> something.
> 
> >-- Steve Majewski
> >
> >
> >
> 
> 
> 
> 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)
> 
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.

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