Re: AS/400 (was: Debugging of optimized code)

SAND_DUANE@tandem.com writes:
> 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).


There are unquestionable advantages to this for the customer.. some obvious
(e.g., instruction set compatibility), and some not so obvious (e.g., some
security checking can be done at link time, as it is for DB2 plan binding).
Unfortunately, I believe these advantages of the AS/400 were always outweighed
by one large disadvantage.


The AS/400, like IBM's never released Future System before it, was designed to
vertically integrate _ALL_ system software (e.g., kernel, I/O drivers,
translators, system utilities, DBMSes)... which gave complete account control
to IBM.


> 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.


Surely you jest! :-)


> Maybe AS/400 users will finally see a 'full
> optimizations with little or no debugging' switch.


I think that's a good idea.


> 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.


Delaying some compiler services (e.g., register allocation to provide software
register window support) and moving forward some run-time services (e.g.,
security checking) to bind (link) time is a great idea... and I think it will
really help for parallelization of shared-memory code too. However, I think
doing more things at bind time doesn't _require_ total vertical integration of
system software...putting those ideas together was a _marketing_
decision...the kind IBM frequently made for mainframes (e.g., putting 31-bit
virtual support and channel subsystem together to form XA, putting access
register support and extensive use of expanded storage together to form ESA).
--
John R. Grout Center for Supercomputing R & D j-grout@uiuc.edu
Coordinated Science Laboratory University of Illinois at Urbana-Champaign
--

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