And also,

Hello,GriV even 10 direct calls via Call can already lead to winnings compared to Call system on Jp. What if there are a lot of them? What if there are a lot of them? And in general, once again - the process of “patching” itself compared to time program loading (which is required) is about 5-10% (for average executive files - for games and dem this figure will be significantly less) - i.e. you downloaded the program, your flopper hasn’t stopped spinning yet the program is already configured - there are only direct Calls and no table in There is no more memory - the purest program. After this, ALL functions are performed quickly - because there are no additional transitions, etc. That. my assessment (plus denotes advantages and minus disadvantages): 1. RST - too slow (-) although it may seem convenient (+) - for each call it takes about 200(-) clock cycles (maybe a little faster) to determine where passed the call; may return with an error (+) - if there is no specified function. Used in old programs as a legacy of the PC interrupt system monsters. The least amount of memory is required to call (+) - about 3 bytes, allows you to take apart procedures from ROM as you like, internal translator addresses will calculate everything and do it (+). 2. Method of set jump points - Jp (Call) to the Jp table inside the ROM - requires about 5-6 bytes from the program (-), but works very quickly (+)compared to the previous version. Conventionally, 20/26 clock cycles are spent per call procedures. Passing parameters (loading registers) requires additional(-) investments (somewhere up to 50 clock cycles maximum), the compiler is required consistency with the ROM version (-), because a direct call/change to ROM can lead to a fatal outcome(?-), almost impossible to control "wrong" calls/transitions (-). An additional table in ROM(-) is required. 3. Direct call method with preset. Implies the presence in table file for correcting call addresses (-) - which requires additional space on the media (4 bytes per point). Requires preliminary setup (-), about 100 clock cycles per call point, but only one setup takes place times(?+), it is not executed anymore. Requires 5-6 bytes for its work (-). Call execution speed is the highest (+) - it simply doesn’t get faster - 10/16 beats Loading registers to parameters increases(-) call time and memory allotted for calling conditionally up to 40 cycles. It is possible to track incorrect call (+) even at the stage of setting up calls - “incorrect transitions". An additional table in ROM(-) is required. I chose the third option for myself, and you? ;)

Hello,GriV I don’t quite understand why the duration of execution of basic operators is needed. Maybe compare the performance of different bass translators? Most likely you won’t find accurate information on operators’ working hours anywhere. - simply because no one needs it.