[lcdproc] Not in perl...

James McCracken merlin_jim@hotmail.com
Sun, 18 Mar 2001 13:37:56 -0500


C was supposed to be the first portable assembler.  That's WHY C compiles so 
efficiently; because it's very easy to translate C-code into the native 
instruction set of so many CPUs.  And I'm a huge advocate of the viewpoint 
that device drivers are going to be the number one most accessed code in 
your core.  So they should be as small and as fast as possible.  Just like 
when you're programming a graphics algorithm, you try to take all the 
inefficiencies out of inner loops (the code you'll iterate a couple million 
times before you're done), it's the same idea here... if the device drivers 
aren't as small and fast as you can get them, then how is the rest of your 
code going to be lightweight and efficient?


>From: "robert smith" <psyfybre@ntlworld.com>
>To: <lcdproc@lists.omnipotent.net>
>Subject: Re: [lcdproc] Not in perl...
>Date: Thu, 15 Mar 2001 22:02:21 -0000
>
>why c? c is for classes, not devices.
>
>----- Original Message -----
>From: James McCracken <merlin_jim@hotmail.com>
>To: <lcdproc@lists.omnipotent.net>
>Sent: Thursday, March 15, 2001 9:09 PM
>Subject: Re: [lcdproc] Not in perl...
>
>
> > Personal thoughts: lcdproc is a device driver.  Device drivers should be
> > written in C or ASM... ASM is not a good choice for portability... but
>this
> > sort of stuff just makes sense to do in C.  Then write a wrapper to 
>access
> > it in other languages.  I personally find the current client/server
> > interface a little tricky, but then I'm generally not a Linux 
>programmer,
>so
> > that could just be my personal skillset...


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net