[aprssig] followup on Rant about cross platform

[Gregg Wonderly]

Jim Lux wrote:
> The idea I was trying to develop was that people developing software for 
> love (which is the vast majority, if not all, of amateur radio software) 
> have to make decisions about how to allocate their scarce resources.  
> The easy decision (because developers for love tend to want to minimize 
> the work making their baby) is to work in what you know, and, 
> statistically, that's not likely to be Java (no matter how wonderful it 
> may or may not be).

I really do appreciate the fact that there is time to be spent learning.  We all 
have to spend the time that we can doing the things that make our lives as 
pleasant and enjoyable as we'd like for them to be.

I think about it this way.  It's really easy to sit on the couch and watch TV. 
If I get up off the couch and ride my bike, I get some exercise.  If I get 
enough exercise, my body might last longer and I might actually get to 
accomplish more than I hoped I could by living through tomorrow a few more times.

In any kind of task that requires learning new things, we all feel put back by 
the concept of the unknown boundry on intervals of time that might be required. 
  Many things are wastes of time.  Others are eye opening, and/or life changing 
that we never imagined the benefits or results.  In the case of software 
development, computer science has not really advanced lately from a technology 
perspective. We are able to create the same type of software faster because of 
IDEs and faster computers.

We largely are still solving computing problems with the same computational 
constructs and flow structures.  Everyone is recreating the same software 
someone else has already created for either a different langauge or a different 
operating system that has specific functional interfaces not supported by 
another programs structure.  This is a tremendous waste of time, and practically 
it creates a division of software capabilities which make it even more likely 
that various pieces of software will not work together.

The development of XML and Web-Services standards are an attempt to allow all of 
these computer languages to share a common form of communications.  This is very 
popular, although it is not a scalable solution for the long run.

The Java Virtual machine supports 100s of languages (see 
http://www.robert-tolksdorf.de/vmlanguages.html).  You can use any of those 
languages anywhere there is a JVM.  This is the same model that .Net is aimed 
at.  Perhaps Microsoft sees these issues and undertands.  But, I think more than 
anything that they are trying to make all languages work on .Net to maintain 
their customer base.  .Net restricts all .Net languages to the features of the 
Common Language Runtime (CLR), which means that their C++ is capable of no more 
than C#, including the loss of multiple inheritence.  So, it comes down to the 
fact that the runtime environments are collapsing into platforms of software 
libraries.  The hardware is getting farther away from the software developers 
thoughts.

> When you talk of DSP code (e.g. the example Gregg gave of a PSK31 
> engine, or some other modem implementation), the likely coder is someone 
> who is almost certainly not from the Java world, if only because Java 
> isn't particularly popular for these applications, especially in an 
> embedded environment.  

There are almost no differences between Java and C for math expressions.  The 
only subtle differences are in getting to more advanced math functions using the 
  the library objects. I don't want to turn this into a how to write Java 
series.  If anyone wants more pointers just send me a request.

> This is not to say that you couldn't write hard-real-time DSP code in 
> Java (Ii suspect you could, with sufficient resources), but rather that, 
> most likely, the code base they would be starting from is more likely to 
> be in ASM or C.   There is a lot of work involved in writing modem code,
> especially to handle all the corner cases and deal with the 
> idiosyncracies of the surrounding environment, while still giving good 
> performance, and most people start with something that they know works 
> somewhere, and then modify it for the new platform.  As they say, old 
> habits die hard.

Any program on a timesharing operating system has to deal with this issue.  At 
some point in a time shared envionment, you won't have the CPU, some other code 
will.  To do DSP code right, you really need to use the operating system 
provided buffering and process it asynchronously, not try and read it one byte 
at a time and risk loss of data.  This is present in most audio processing 
applications that I've seen these days.   The built in buffering and audio I/O 
facilities in windows is largely why using the audio card on PCs has gotten so 
popular.

Audio processing in most amatuer radio operations is not that compute intensive. 
  Optimizations are typically being done for the numbers it seems to me.  If 
your DSP code is that tight against the wall on a PC, you really need to just go 
get a DSP board and build an embedded system.

Call you analog phone on you digital cell phone and listen to the delays created 
by the digital audio processing systems that are part of those systems.  We all 
know these delays are there.  We interrupt each other sometimes because of the 
delays leaving holes in the coversation.  If the commercial systems can't get by 
without these delays, what makes us feel that we have to try so hard to achieve 
absolute hard realtime results?  It's not possible on a timesharing OS.

> I'll also comment that in many of the DSP projects I've been involved 
> in, the non-determinism of timing in standard Java would make it an 
> out-of-the-gate non-starter, even if it were available for the target 
> processor.  Sure, one could probably come up with a custom 
> implementation of the JVM/JRE with appropriate determinism, hooks to the 
> hardware, etc., but then, you're not in the "write once, run everywhere" 
> model anymore.  I readily confess that I know next to nothing about how 
> one might even start doing this in Java.

The first thing that is important is to realize that Java has queuing and 
threading support that makes it trivial to create a thread that is reading data 
from an audio stream and queuing it to a processing queue.  Another thread can 
read from that processing queue, and process the audio data and then queue it 
for use by a third thread.  This allows multi-processor/multi-core computers to 
trivally become more powerful to the user by overlapping latency.  This is not 
available in standard C/C++ (except through 3rd party libraries or OS specific 
features) and many other programming environments have no support at all.

> I understand that there are 
> efforts being made to create a "real-time Java", but, it's nowhere near 
> as mature as the existing body of knowledge in Asm or C (better the 
> devil you know, etc.). But this gets back to the point about people tend 
> to want to work in the environment they are familiar with, which, 
> statistically, is not Java.

At Javaone this year, I wrote Java software using the RTSJ (Real Time System for 
Java) implementation that Sun has done for Solaris.  That Java software drove a 
slot car around the track.  I had the input of track position markers.  I could 
thus see where I was on the track and my speed (time between markers).  For 
output, I could drive a Digital to Analog converter that provide control of the 
power present on the track, and braking.  I had to go around the track twice, 
once on the inside and once on the outside.  I was about 13th out of 100 or more 
contestants.

Real Time is about predictable scheduling more than anything else.  The RTSJ 
(which you can get for a few other processors, but which only makes sense for 
time sharing systems), is a solution that exists now as a specification and has 
some existing implementations.

There are processors such as the AJile microcontroller which run Java directly. 
  The 100mhz version of that processor is very power conservative by design. 
There are demos of it doing MPEG video decoding, without any jitters or hiccups 
in processing.  So, realtime is possible for Java.  Most audio/video 
applications are mostly about applying some very specific software architectures 
to manage the issues that you might have on your target platform.  You have to 
do that for any language though.  Java happens to provide the same APIs and 
programming constructs on all platforms.  That makes it easier to write it once 
and run it anywhere.

> So, it's a pretty bold request to ask a volunteer to take on not only 
> coding/porting up some sort of modem (a non-trivial task in itself, but 
> one that is small enough to be done in a reasonable time ), but also to 
> ask that they learn a whole new computing environment, with just as many 
> idiosyncracies as, say, Windows.  

This is an important issue.  I don't think though that there is as large a 
barrier as some perceive.  I think that there are differences which feel very 
different because of limited experiences.  But, those things can be gotten past 
fairly easily with someone who can help you think in the right way to get started.

 > You'd probably have to show that the
> new environment provides some really useful functionality (to the 
> volunteer) that they currently don't have available, or that is a pain 
> to get.  That is, it will make their job noticeably easier if they 
> adopt, for example, Java. An appeal to an abstract altruism: "it will 
> help society in the future" is a much harder sell.  It's true you've at 
> least got them volunteering in the first place, so it's not a totally 
> lost cause.  There's a similar discussion going on in the SDR-1000 world 
> about the adoption of a language called Erlang.

When I started using Java seriously, I did it mostly because of garbage 
collection/memory management.  There was enough support in Java1.0.1 with the 
Hashtable and Vector classes, for the programming structures that I used most 
often, that I no longer had to manage any memory stuff myself, other than 
dropping references to things I didn't need to use any longer.  This was in 
1995/1996 when there were still not too many interesting libraries for C/C++ 
related to data structures management.  A decade later, everyone has looked at 
the power of the Java platform's libraries and found the convenience of them to 
be attractive.

Look at what Microsoft has done in developing .Net.  They took the concepts of 
the java platform and wrapped it in Microsoft covers so that they could change 
more things to tightly integrate it into their OS (the java license that they 
had did not allow private changes to be made public as they were doing with 
J++).  Windows has a lot of things that are very specific to the OS design and 
to the historical line of the development of the windows programming model. 
Many of these things are different from other OS and GUI environments, and that 
is one of the big factors which makes portability of software very difficult.

There is a lot more of the OS and hardware visible in the windows APIs than 
there is in many other more portable software systems.  So, you have to consider 
those issues to manage portability when writing software with certain language 
environments.

> Gosh, people are still developing applications for ham radio that are 
> based on MS-DOS, and probably modified from code originally written for 
> a Z80 running CP/M.  In that context, Java is just a young stripling 
> with a lot of growing left to do.  And, I see ham radio software moving 
> towards a more "componentized" implementation, with cleaner interfaces 
> among components.  I really shouldn't care what langauge the PSK engine 
> is written in, as long as it's available for my platform and it has the 
> right hooks to make it work.

Right, and that's my biggest concern.  No one seems to see the benefits of 
crossplatform portability with clear enough sight to understand the larger 
benefits that we might actually be able to reach by using portable software. 
Imagine being able to write modules to plug into a users environment, instead of 
having to write a whole application framework, and then make the user sort 
through your UI and learn how to use it.

I know a lot of this sounds like a pipe dream.  But, there really is a chance to 
make a dramatic change in how software for Amatuer Radio applications is done. 
It's just a matter of people deciding to, and being able to get engaged in 
making the change toward open/portable systems happen.

I'll leave it at that, I've certainly gone on for more that I intended.

Gregg Wonderly
W5GGW