This is an interesting observation about some of details required to implement the 'model of computation' of a SystemBuild model within the generated code.
Before I continue, may I make a suggestion that if you intend to use procedure code outside of a complete autocode-generated system, you might want to consider using the SDK interfaces. Briefly, the SDK is a template-based solution to generate APIs (C, C++ or Ada) to properly call procedure SuperBlocks from 'other' code. It's very easy to use and implements all the necessary details. Consult your version's documentaion for more as the mechanism to activate the SDK have changed between versions but the structure of the APIs are the same.
Now, on to the post...
The most important detail regarding this question is the context of the generated code. In this case, you're using the UCBHOOK mechanism and trying to call that API from other code.
The problem is that the UCBHOOK is designed to be used as "wrapper code" around an autocode procedure and the 'hook' code is intended to be linked back into the simulator as a UCB for simulation purposes. It was not intended to be a general-purpose API call, that's why we created the SDK!
Because the UCBHOOK is designed for use with the Simulator, that code must conform to the requirements of a hand-written SystemBuild UCB. And it is in attempting to match the autocode-generated implementation with what the Simulator does results in some odd code.
What's happening is the code is reflecting a difference in how states are initialized within the Simulator's UCB context and the generated code. Briefly, the simulator must be very generic in how it calls UCB code. The simulator makes many separate calls to a UCB to perform match distinct operations, thus the complexity of the iinfo structure.
Now autocode generated code is not generic, it is optimized. So, in the case of a procedure, a procedure is a form of a discrete superblock with inherited timing attributes. Autocode optimize discrete superblock initialization by initializing it at the same time as the output computation at T=0.0. Therefore, for autocode discrete-based superblocks, there is only ONE init phase and it's coupled with the first OUTPUT phase.
So, since the Simulator does not perform such optimization, the Simulator calls the UCBHOOK several times, as it is documented. This is incompatable with the autocode code, therefore there's code in the UCBHOOK (as you've hilighted) to prevent extra initialization as to match the autocode implementation.
Like I said, the UCBHOOK is designed as a UCB that conforms to the Simulator's 'model of computation'.
If you intend to have your 'outside' code use the ucbhook, you will have to match how the simulator calls UCBs. In the case you describe, calling the UCBHOOK multiple times for initialization is required.
In general, I'd not recommend using the UCBHOOK called from 'outside' code, I'd prefer you use the SDK as the complexity of the simulator's calls to UCBs is not trivial.
Regards,
Bob Pizzi
MATRIXx R&D - AutoCode