Letters

First, Byron suggests that "...code changes could be isolated to the task scheduler. However, the logic involved to determine idle/nonidle tasks is more complex than simply setting the pin in the idle task and resetting the pin in the task scheduler." But Listing Two then takes the trouble to determine whether the task being scheduled is indeed the idle task!

This could be simplified in either of two ways: (1) Have the idle task continually set the output pin; but always reset the pin in the scheduler when the current task is preempted—it doesn't matter whether you're preempting the idle task or another task. Alternatively, (2) Change the scheduler pseudocode in Listing Two(b) to the following:

 ...

 if ready task is non-idle task
    reset output pin
 else
    set output pin

and there is no need to change the idle task at all.

I also suggest another method for observing the duty cycles: Put LED(s) on the output ports. The LED brightness corresponds to the duty cycle, although some "calibration" may be needed to learn the mapping between brightness and duty cycle. This has the advantage that you can have one LED per task (assuming you have enough I/O ports); and, unlike the multimeter, the LEDs respond very quickly, so you can get a good idea of how bursty the processor utilization is.

James H. Puttick

james.puttick@kvs.com

JPEG Prior Art

Dear DDJ,

By now you will have heard the breaking news about the Forgent JPEG patent (http://patft.uspto.gov/netacgi/ nph-Parser?Sect1=PTO1&Sect2=HITOFF&d= PALL&p=1&u=/netahtml/srchnum.htm&r= 1&f=G&l=50&s1='4,698,672'.WKU.&OS= PN/4,69,672&RS=PN/4,698,672). I dug out my copy of Anthony Ralston's Encyclopedia of Computer Science (1976) and, to no particular surprise, found on page 635 in the article on "Image and Picture Processing" an actual example of the Fourier transform image compression, copied from a 1972 Proceedings of the IEEE paper. Needless to say, the patent cites no journal literature whatsoever. When I was a young man, I bought my copy of Ralston for $32.00 in a moderate-sized used bookstore. It is not exactly a rare book.

Andrew D. Todd

adtodd@mail.wvnet.edu

Little Languages

Dear DDJ,

I'd like to respond to J.G. Owen's letter (DDJ, July 2002) regarding little languages.

One size doesn't fit all, and one language doesn't fit all problems either. J.G. states that he believes that UNIX/Linux has a proliferation of little languages because of the irritation factor of compiling C, and that if UNIX had had a fast compiler like Turbo Pascal, things would have been different.

The reason we have many languages on UNIX is because there are many different problem domains, and no one language fits them all well. C is a nice language for system programming, but it doesn't do everything well. If I am going to do heavy duty math, I'll pick Fortran; if I'm going to work with mainly text data, I'll pick Python, Perl, or Ruby before C. That isn't to say that you can't do math or text manipulation in C, but it is certainly easier to do them in other languages.

J.G. submits that the tiny languages were crushed on Windows by the Turbo compilers because they were better. However, Windows didn't initially get the scripting languages at least partially because of cost. On Windows, all compilers cost money until fairly recently and the Turbo languages were always cheaper than the competition, in addition to being faster. And because exploring a new language cost money, people avoided using any more than the minimum required.

In contrast, in the UNIX world, without the entry barrier of price, people are more willing to experiment with other languages to see if they fit the problem better than C/Pascal did, and typically they do. Also, UNIX spent its early development time in research and academia, where creating a specialized language to solve a problem is not considered an unreasonable solution—Perl started out as a report generation program and only later grew to be more general purpose. Additionally, because on UNIX the standard is to create many small tools (my Mac OS X laptop has 1422 programs in /bin, /sbin/, and /usr/sbin) to do different tasks and then connect the output of one into the input of another, scripting languages that make that easier have a much higher payoff than they do in Windows, where the GUI typically can't be easily manipulated from the command line.

It's interesting to observe that once GCC made it to Windows, the tiny languages followed shortly afterward. And now on .NET, we're seeing projects to move Perl and Python there as well.

Joe Block

jpb@ApesSeekingKnowledge.net

DDJ Archives

Dear DDJ,

It looks like you have settled on 1988 as the beginning of the modern computer era. All of your recent collection CD-ROMs begin with that year. How soon can we expect a single CD with just the first 12 years of DDJ?

Why? I used to have a collection of the first six bound volumes of DDJ. Beginning with Tiny BASIC, and then Tiny C, it was a useful reference for ancient history and to study code examples that were much simpler than needed for modern (overgrown) APIs. Then I lost all of those books due to some family problems, and was only able to replace two of them. Recently, I became interested in the Z80 and Z180 as an embedded processor core for personal use, both in ham radio and model railroad (HO scale) applications. CP/M would be the most likely candidate for a basic kernel on those processors, but the early 8085, Z80, and CP/M issues of DDJ were among those that I lost.

There is still an active core of CP/M users, enough to keep one Usenet newsgroup and several web sites alive. There should be interest in republishing at least some of those early issues.

Bob McConnell

rvm@cbord.com

DDJ Responds: Thanks for your note Richard. Frankly, January 1988 was a somewhat arbitrary choice when we started the DDJ CD-ROM project, although it was always our intent to work back in time in parallel with working forward. Alas, the road to Washington is paved with good intentions. Nor do we have electronic files for those early years. Still, it is on a burner, albeit a back burner.

DDJ