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 Edward Jaffe:
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.
