|
|
| Author |
Message |
twesthoff
Joined: 17 Mar 2006
Posts: 199
Location: Fredericksburg, VA
|
|
Posted: 16 October 2007, 23:13 PM Post subject: Inline |
 |
|
Don,
Is there an "Inline" feature of the compiler that will repeat the code for a sub wherever it is called, rather than using a Gosub/Return?
The reason I am asking, is that to speed up my program, and reduce the nesting of Subs, we repeated a lot of the code that was in some subs. Now that I wanted to make it multi-tasking, it is a nightmare to keep track of them and add either semaphore or LockTask code in them. It would be easier to have the code in one place obviously.
Tom |
|
| Back to top |
|
 |
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 16 October 2007, 23:53 PM Post subject: Re: Inline |
|
|
| twesthoff wrote: | | Is there an "Inline" feature of the compiler that will repeat the code for a sub wherever it is called, rather than using a Gosub/Return? |
There is not currently a way to inline a sub. It is something that we have discussed but, so far, we have not worked on it. |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 22 October 2007, 1:35 AM Post subject: Re: Inline |
|
|
| twesthoff wrote: | Don,
The reason I am asking, is that to speed up my program, and reduce the nesting of Subs, we repeated a lot of the code that was in some subs. Now that I wanted to make it multi-tasking, it is a nightmare to keep track of them and add either semaphore or LockTask code in them. It would be easier to have the code in one place obviously.
Tom |
I would also look at other areas of the code for performance increases to reduce the stack space. For example specifying an expression to use the minimum stack space i.e. a + b*c uses more space than b*c + a. Worse case you could always move to a ZX device with more RAM memory. Is 60.75K enough?
Unrolling of functions usually provides only 5-10% performance increase and saves a little stack space. As you have now learned (or may be you already knew), sacrificing code maintainability for a small performance increase is not usually worth it. I would put back your subs, do the multi-tasking and then performance optimization.
If you want help with performance optimization I would be willing to review your code - contact me offline. We can work out a confidentiality agreement if that is a concern.
[Aside] Just like functions and subroutines, tasks benefit from being small and self-contained. I would be worried if you have to add task locking and semaphores in multiple places. This means you probably didn't isolate the shared data very well and introducing multitasking at this point may result in weeks of frustrating code debugging. One best practice (borrowed from Java Beans) is to use accessors to retrieve private task data. That way you can add a lock or semaphore in only one place in the code. This is even more true when there are only some valid combinations of data and these rules can be enforced by accessors. Here is some simple example code:
| Code: | Private sharedData as Long
Public Function GetData() as Long
GetData = sharedData
End Function
Public Sub SetData(newData as Long)
' data access mechanism
sharedData = newData
' release data
End Sub |
|
|
| Back to top |
|
|
twesthoff
Joined: 17 Mar 2006
Posts: 199
Location: Fredericksburg, VA
|
|
Posted: 23 October 2007, 1:21 AM Post subject: Re: Inline |
|
|
| mikep wrote: |
I would also look at other areas of the code for performance increases to reduce the stack space. For example specifying an expression to use the minimum stack space i.e. a + b*c uses more space than b*c + a. Worse case you could always move to a ZX device with more RAM memory. Is 60.75K enough? |
I don't think I am running out of memory yet. I have about 3.5K in the '44b we are using. The program map file shows 114 bytes being used. I used 300 bytes more to make a buffer that allows me to save a lot of time processing, but took slightly longer to read into the buffer... an overall gain. I have not yet seen any heap or stack overflow problems, but have not been able to quantify it yet to be sure. (I thought it could have been a problem, but now think I need more speed/efficiency.)
| mikep wrote: | | Unrolling of functions usually provides only 5-10% performance increase and saves a little stack space. As you have now learned (or may be you already knew), sacrificing code maintainability for a small performance increase is not usually worth it. I would put back your subs, do the multi-tasking and then performance optimization. |
When you are close to the edge 5-10% is quite good. I measured more like 25%. I had to do it when using a slower processor previously, and so left it in when using a faster one. I am planning to use the '1281 on the next board, just need to get this to work until then, when the program will be completely rewritten anyway.
| mikep wrote: | If you want help with performance optimization I would be willing to review your code - contact me offline. We can work out a confidentiality agreement if that is a concern.
[Aside] Just like functions and subroutines, tasks benefit from being small and self-contained. I would be worried if you have to add task locking and semaphores in multiple places. This means you probably didn't isolate the shared data very well and introducing multitasking at this point may result in weeks of frustrating code debugging. One best practice (borrowed from Java Beans) is to use accessors to retrieve private task data. That way you can add a lock or semaphore in only one place in the code. This is even more true when there are only some valid combinations of data and these rules can be enforced by accessors. Here is some simple example code:
| Code: | Private sharedData as Long
Public Function GetData() as Long
GetData = sharedData
End Function
Public Sub SetData(newData as Long)
' data access mechanism
sharedData = newData
' release data
End Sub |
|
The problem I was having with the tasks, was that a port was being used as a bus for multiple chips. The ALE, RD- and WR- pulses are bit-banged, and the tasks were both trying to use the bus. One task would start the pulses, and then the other task would either finish them or start in the middle of it. Due to a hardware design error I inherited, it is even more dificult. It is time consuming to find all the code that was unrolled to do the locking. More of a time constraint, than a difficulty. Since I will be rewriting it soon mostly from scratch anyway. The new hardware will almost eliminate the issue.
The real problem is reading the fifos from the other chips fast enough and often enough (I think... haven't proved that yet). I thought the BusRead() would help, but as it is implemented now, it won't work properly. I have spoken to Don about this offline.
Thanks for your offer to look at the code, but I don't think it wouldn't be worth the time right now. I have a few things I can do that I haven't tried yet.
I would like to know how the code examples you gave could speed anything up or help with multiple tasks.
Tom |
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Posts: 771
Location: Austin, TX
|
|
Posted: 23 October 2007, 6:34 AM Post subject: Re: Inline |
|
|
| twesthoff wrote: | | I don't think I am running out of memory yet. I have about 3.5K in the '44b we are using. |
Ok so I understand this is an inherited problem from BasicX when memory was much more of a problem.
| twesthoff wrote: |
I would like to know how the code examples you gave could speed anything up or help with multiple tasks. |
The purpose of the code was to show how to isolate accesses to shared data into one place. It is a design point to improve code maintainability. |
|
| Back to top |
|
|
|
ZBasic Home
Forum Rules
Memberlist
Usergroups
RSS Feed
Site Search
Links
Download
Digests and Subscriptions
Profile
Log in to check your private messages
Log in
Register