Comments (2)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 RickSchoonmaker commented Permalink

We received the following comment today on the old TPF Blog, so I am moving it forward to the current TPF Blog. <div>&nbsp;</div> "Assembler macro calling c program which is passing more 50 parameter, but CPROC we can able to specify only 12 parameter so when it comes to c program first 12 parameters received correctly but remaining parameters are corrupted. Is there any possible way to do this in z/TPF like it is correctly working in TPF 4.1?"

2 Jim.Tison commented Permalink

The interfaces between system services and assembler applications programs are implemented as macros in z/TPF and its predecessors. These interfaces are documented (see for older versions, such as TPF 4.1, or for the current version). By following the rules stated in the documentation, the defined interface is used, and IBM will respond &amp; correct any instance you report of improper behavior at runtime. <div>&nbsp;</div> If you'll look up CPROC in both sets of documentation above, you will see clear statements of "A maximum of 12 parameters can be specified", prominently displayed in both versions. This statement defines the design limit of the CALLC interface. If the interface should just so happen to allow 13 or more in spite of what the documentation says, then you use the interface that way at your own risk. In other words, undefined uses of defined interfaces are in the same category as using undefined interfaces. That is to say that compatibility is not supported, as you see. <div>&nbsp;</div> There are better -- and officially supported -- ways of passing that much data to a function. I've always recommended that such data be stored in memory, then pass its base address to the function we're calling. This is called "passing arguments by reference". Whether your program does it (by procedurally laying out the data in memory) or the compiler/assembler does it for you (by building an argument list and then addressing its elements) makes little difference in terms of performance. Where it matters is in forward compatibility; one way will definitely not be supported, but an alternative might be. <div>&nbsp;</div> I hope this helps. <div>&nbsp;</div> Good luck! <br /> --Jim--