Oppolzer - Informatik / Blog

We, too, have at our site a macro which supports the creation of automatic
storage, but at the module level. This is ok and it would solve the problem of
recursive calls. But it is far too expensive for a recursive function like
quicksort etc., where recursion is heavily used and where the saving of all
registers and allocating save areas etc. in the traditional way is not really
needed.

The solution at our site also carries a lot of historical burden (AMODE
considerations etc., LOADing module the first time, then BALR), so it is simply
not usable for recursive procedures at the "algorithmic" level.

LE makes some compromises, because it tries to simplify the prolog/epilog effort
as far as possible, so I believe that in such cases C will outperform ASSEMBLER.

But anyway: even LE is too slow, and that's why IBM invented XPLINK. I don't
like XPLINK very much, because it makes trouble with other languages like PL/1
etc., but: there must be a problem, because there is a solution like XPLINK.

Kind regards

Bernd



Am 09.04.2011 21:11, schrieb E.J.:
> On 4/9/2011 11:50 AM, Bernd Oppolzer wrote:
>> Many algorithms, for example quicksort or walking thru binary trees
>> or inserting into balanced trees like AVL trees etc., need to be written
>> as recursive functions or procedures. If you want to do this in ASSEMBLER,
>> you have to do all the housekeeping etc. to get the many incarnations of
>> variables of the recursive invocations of that functions. Or, you need
>> arrays to simulate the recursion stack etc., which means storage management.
>> Anyway, you have to deal with it. This management has to be done by
>> the ASSEMBLER programmer.
>
> Our register save/stacking macro allows for the creation of 'automatic'
> variables in assembler. (They are on the stack.) We use recursion all the time
> without giving it a second thought. I assume most serious assembler language
> software developers have infrastructures with similar capabilities. I could be
> wrong.