On 22 November 2012 13:51, Paul Gilmartin <[email protected]> wrote: > On Nov 22, 2012, at 10:08, Tony Harminc wrote: >> >> But there are significant missing pieces that make life quite >> difficult for many cases. Notably, the input and output types of >> external functions are constrained to be the same, so that one cannot >> write an external function that takes, say, character (SETC-type) >> input and returns numeric (SETA-type) output. >> > Strange. Is it because: > > o The external function uses the same storage area for its argument > and its result?
No. > o There's no way to declare the result (and argument) type of an > external function? The types are fixed by the <verb>: SETAF, SETBF, or SETCF. > Can an external function take multiple arguments? Yes. > If so, can the arguments be of different types? No. > Is the result type the type of the first argument? If so, one could supply a > dummy first argument > just to set the the result type, and the real arguments in &2, &3, ... N/A. > What happens if an external function called with a SETB-type > argument attempts to return, for example a SETC-type result? It can't. That is, the user code has no choice about the return format. > Must the arguments and results of external functions be self- > defining terms, or may the be, for example, relocatable address > values? Um... I'd better defer to John, but I think the values must be available at macro time. > What are the first-class objects of HLASM (at assembly time, not at > execution)? A good question, but I'm not sure that it's well-formed enough. Tony H.
