I'll take a stab at this. EQU, which is a compile time construct shouldn't make ANY difference. In real time, it probably doesn't.
But, back in the old days on PICK implementations (I don't know if it's still this way), the compiler inserted a "NO-OP" (no operation instruction) into the object code wherever EQU was used to act as a placeholder for the line counter. This way, if you went into the debugger, the line number you broke at could be returned. So, one could argue that if there were enough NO-OP instructions, there could be a difference in execution speed. It was a tough argument back in the day of 6MHz systems with 4MB RAM, but, valid nevertheless. We actually put EQU strategically into the object code where it would cause a frame fault that resulted in losing the time-slice to prove the point. However, that was then... Best regards, Jim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: Saturday, November 18, 2006 1:06 AM To: [email protected] Subject: RE: [U2] [UV] Question about EQU David, I am interested in your opinions as to why, given that equates are compile time constructs, would have any impact at all on execution speed. Understand, I am not contesting your premise, but rather would simply like more explanation to understand your perspective. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com ** Check out scheduled Connect! training courses at http://www.PrecisOnline.com/train.html. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
