Re: Need info on incremental compilers.

march@iis.nsk.su (Mark Marchukov) writes:


> I would appreciate any pointers to info about incremental compilers:
> books, articles, ftp-able information.


This probably isn't particularly useful to you, but in the world
of industrial process control, something similar is fairly
common. Engineers programming PLCs (programmable logic controllers)
often use a graphical language called Ladder Diagram (LD), which
is based on hardware relays. It uses "scans" - programs are a single
large linear piece of code which is repeatedly executed in a fixed
loop.


When commissioning systems on site, engineers often need to make
modifications to the LD code, which are expected to be applied very
quickly - recompilation of the changed LD code is expected to take
only a few seconds. Also, PLCs often support a facility called
"hot swapping". The PLC has two program areas, one of which is in
use at the time. When a modification is made, the changed code is
loaded into the second area, and between scans the PLC switches to
using the second area (it's often possible to alternate between
the two areas). Note that this usually affects code, but not the
data that the code operates on.


> I am particularly interested
> in the environments that support incremental compilation of
> procedural languages such as C and Pascal.


As you may have guessed, what I'm describing is lightyears
away from Pascal. IEC-1131-3 does define PLC programming languages,
including one that resembles the Algol family, but that's just a
front - the semantics are rather unpleasant. It's still scan-based,
too.


> 1) Are there faster alternatives to the classic edit--compile--link--run
> procedure other than incremental compilation and interpreters?


Well, the above hot-swapping method is one solution, but I suspect it's
to a different problem from the one you're considering.


> 2) Do we need such alternatives at all?


I suspect that depends entirely on your intended uses. I for one am
more concerned about a decent development environment that helps
me to get the program right first time (ha!), and that generates
code that runs quickly. PLC engineers, on the other hand, are used
to making quick hacks to their systems (they're usually hardware
engineers with no software methodolgy background), and having got
that quick turnaround now, they don't plan to give it up easily.


As a final comment, the SPARCWorks 3.0 debugger on SunOS 5.x
supports something Sun calls "fix and continue", which basically
comes down to dynamically linking in a modified module, and
Pure Software Inc (have I got the name right?) sell an incremental
linker. Either company may have white papers on their respective
offerings.


steve
--
<Steve_Kilbane@cegelecproj.co.uk>
--

Return to the comp.compilers page.
Search the comp.compilers archives again.