AS/400 (was: Debugging of optimized code)

DanHicks@aol.com writes:
> particular optimizations that thwart debugging can be avoided
> (without having to generally reduce the level of optimization) and
> optimizations that ARE performed can be made known to the debugger.
>
> Associates of mine who worked on the AS/400 V2R3 ILE optimizer made
> some small progress in these areas, but the challenges are too
> daunting to expect much progress very fast.


The IBM AS/400 is a great example of the real need for civilized
optimizers in the commercial computing world.


The AS/400 tool set aims to totally hide ALL details of the instruction
set from ALL users; everything the customer's program does is explained
and shown only in source language concepts. There is apparently no
customer-available manual describing the instruction set(s).


I read somewhere that the output from AS/400 compilers and linker is not
directly executable by the machines, but instead is in some generic
abstract instruction set. This code is then translated (invisibly) into
the executable code of a particular model of the AS/400 when the codefile
is installed or first executed on that machine. The AS/400 family has had
various processors with different non-compatible actual instruction sets,
all without disrupting the compatibility of customers' generic object
files. The next models will be based on some variant of PowerPC, again
using load-time translation to hide all the many incompatibilities.


The portability goals are a bit like ANDF, but customers don't notice
it happening.


The instruction sets of the AS/400 are deliberately a mystery. Can
anyone sketch for us the nature of the generic instruction set and one
or more of the existing actual instruction sets? And how about the
performance and methods of the load-time translators?


Anyhow, back to debugging. If AS/400 users are to remain totally
ignorant of all instruction set details, then the debugger must always
do a very good job of describing every visible effect in original
source program terms, whether or not the compiler or load-time
translator does optimizations. The debugger can't ever give up,
and simply show the instruction stream and register contents.


On this product line, when the debugger and optimizer can't work out a
way to jointly support some optimization, it's the optimizer that loses,
not the debugger. And so the peak performance and price/performance of
the machine is held back somewhat from what other companies with
different policies could achieve with the same hardware and compilers.
That was okay in the past, since AS/400 was a low- to mid-range product
line and IBM's profit margins were very fat. I imagine they are less
happy with such compromises now.


Imagine that you are designing the AS/400 load-time translator for a
risc chip with lots of registers, essentially the same chip that
is being used by other subdivisions and other companies for running
Unix and Macs and NT and OS/370. You'd want to do all the profitable
optimizations that others are doing, to stay competitive. But you
can't break the symbolic debugger! That's daunting.


Maybe IBM will stop being coy about the executable object code level,
since it's going to be an un-clonable variant of the open PowerPC
standard anyhow. Maybe AS/400 users will finally see a 'full
optimizations with little or no debugging' switch.


IBM's policy of not allowing users to see their own object code is not
something that other companies should imitate. But making object code
browsing (usually) unnecessary is a good goal for us all.
--

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