> You and Olin both mention programming in Pascal. Is this maintaining
> old code or just continuing to use tools that you like? I did a lot of
> Pascal programming 15 years ago but that all got ported to C and
> assembler.

I use only assembler on PICs and other small resource-limited systems.

I use Pascal for "big machine" or host code.  15 years ago I was working
on 3D visualization software that needed to run on many different
workstation platforms.  The strategy for porting was to write portable
code in the first place that didn't need porting.  We looked into writing
everything in generic C, but that language was just too awful.  I was used
to Apollo Domain/OS Pascal, and going to C felt like too much of step back
to the dark ages.  C++ was not ready at the time.  We decided to continue
development in Pascal using a source to source translator so that our code
could be compiled with whatever the best compiler was on each platform,
which was C in most cases.

This turned out to be very useful for other reasons besides changing the
language.  The translator back end could be customized to work around
specific bugs in the various compilers.  It also meant we owned the master
source language and could therefore extend it to include a few nice
portability features.  At one time we had the 3D visualization software
running on Apollo Domain/OS, IBM Aix, Sun SunOS, Silicon Graphics Irix,
and HP HPux.  All of these versions were automatically generated on the
fly from the same Pascal app-level source code which did not contain
things like IFDEFs.

The other part of the portability environment is a set of low level
libraries that provide an operating independent interface for things that
all operating systems do, but most do differently.  This includes stuff
like file I/O, getting the system time, threads, processes, etc.  These
were deliberately designed to be easily ported, and did contain modules
with different version for different target systems.  If I remember right,
except for graphics, only about 2000 lines of code were different between
Domain/OS and the various Unix flavors.  The Unix flavors differed from
each other by less than 1000 lines of code.

3D graphics is another separate portability problem.  We addressed it the
same way by creating RENDlib, a device independent graphics library that
was designed so that any routine could be implemented by a specific
"driver", or default to the generic routine that called lower level
routines.  All you had to implement on each platform was the write pixel
call.  Everything else was just for efficiency.  We had versions for
Apollo GPR/GMR graphics, Silicon Graphics GL, X Windows, and a few custom
devices we had to support.  Meanwhile a Windows GDI driver has been
implemented.

The app code didn't know nor care what was underneath.  It all just
worked.  I can imagine a Linux with X windows version in the future.

I'm probably willing to make the translator available publicly if anyone
still cares about Pascal out there.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body