> 32K is no longer a limitation. Some list members released 32-bit patches a
> while ago. I don't know that this body of work is complete, but as far as I
> know, it does work well enough.
32k may no longer be an excuse, but the uClinux runtime libraries (at
least the one's in RT-Control's distro) probably wouldn't cut it.
> > uClinux is for embedded applications. Perl is not for embedded
> > applications.
> Ehhhhh..... well, that may be a hard generalization to prove. Like I said in
> another post, PERL isn't really an intrinsically good match for a uCsimm,
> but there is a company out there that uses a 90MHz ColdFire processor with
> uClinux as the OS (they make a small router); PERL might be an excellent
> tool for something like that.
The speed/size issue may not exist for more advanced uClinux based
systems, but I wouldn't trust Perl for most embedded work. I say this due
to the fact that Perl is dynamically typed, and the interpreter is not the
cleanest code I've ever read.
I'll close my side of the argument with an extended quote from the Perl
FAQ at perl.com
For various reasons, Perl is probably not well-suited for real-time
embedded systems, low-level operating systems development work like
device drivers or context-switching code, complex multithreaded
shared-memory applications, or extremely large applications.
You'll notice that perl is not itself written in Perl.
The new native-code compiler for Perl may reduce the limitations
given in the previous statement to some degree, but understand
that Perl remains fundamentally a dynamically typed language, and
not a statically typed one. You certainly won't be chastized if
you don't trust nuclear-plant or brain-surgery monitoring code to
it. And Larry will sleep easier, too -- Wall Street programs not
--- Geoffrey Wossum firstname.lastname@example.org Project AKO - http://rover1.uta.edu/~ako Internet Imperialists - http://inetimperial.sourceforge.net This message resent by the email@example.com list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:35 EST