AutoVIDC extASM issues
AutoVIDC extASM issues
Did you up the latest module to the FTP site? I think I'm looking at a copy prior to your latest changes.
Re: AutoVIDC extASM issues
The copy on the server (AVIDC209.zip) is time stamped 19th May and was the most up to date version.
However I've just uploaded a new version (AVIDC209test.zip) (leaving the previous version on the server too) which builds to a module size of 7428 bytes with the FAST option enabled.
It's presenting the same issue as the previously uploaded version in that it will not build correctly without the FAST option being set.
Paul
However I've just uploaded a new version (AVIDC209test.zip) (leaving the previous version on the server too) which builds to a module size of 7428 bytes with the FAST option enabled.
It's presenting the same issue as the previously uploaded version in that it will not build correctly without the FAST option being set.
Paul
Re: AutoVIDC extASM issues
If it doesn't already, can you up a compiled version of the module with:
Fast off
Shrink on
Only ADR/LDR on (can't remember the exact name)
This is so I can do a quick binary comparison - if it comes out the same I'll know the issue is still there.
Fast off
Shrink on
Only ADR/LDR on (can't remember the exact name)
This is so I can do a quick binary comparison - if it comes out the same I'll know the issue is still there.
Re: AutoVIDC extASM issues
I've uploaded a zip file called latest. It contains the latest source and in the Module folder there are two builds of the module. One with fast enabled (AVIDCwrk) the other as requested (AVIDCbrk). The difference in file sizes for the two modules is now 72 bytes and they appear to have some actual differences as well as just extra bytes here and there too.
Paul
Paul
Re: AutoVIDC extASM issues
I can see a problem in the make file:
SWI_Names doesn't have an ALIGN after it, so the SWI entry point isn't word aligned.
SWI_Table needs to move outside of the SWItable area as its readonly.
SWI_Names doesn't have an ALIGN after it, so the SWI entry point isn't word aligned.
SWI_Table needs to move outside of the SWItable area as its readonly.
Re: AutoVIDC extASM issues
Incidentally, if you're on a quest for bytes, you could recode SWI_Table along the lines of:
In SWI_Funcs there's a TEMP R10-R12 at the top, but no LOCK to release them. If this is to be used for the whole file, you should really stack/unstack R10-R12 on every entry / exit. You don't actually need the TEMP as there are no auto-expansions that require it, I'd advise removing TEMP R10-R12 completely.
Code: Select all
.AutoVIDC_SWI
ADR R12, _SWI_jump_table
CMP R11, #(_SWI_jump_table_end - _SWI_jump_table - 4) / 4
ADDLS PC, R12, R11, LSL #2
TEQ PC, PC
MOVEQ PC, R14
MOVS PC, R14
._SWI_jump_table
B AutoVIDC_SetClockSWI
B AutoVIDC_DelegateControlSWI
B AutoVIDC_IsDelegatedSWI
B AutoVIDC_IsOverClockingEnabledSWI
B AutoVIDC_ModeSyncPolaritySWI
B AutoVIDC_ReInitSWI
B AutoVIDC_ClockAvailableSWI
._SWI_jump_table_end
Re: AutoVIDC extASM issues
But it does in the make file. I'm now officially confused! Were you looking in the file itself?JonAbbott wrote:I can see a problem in the make file:
SWI_Names doesn't have an ALIGN after it, so the SWI entry point isn't word aligned.
Ok.JonAbbott wrote:SWI_Table needs to move outside of the SWItable area as its readonly.
There is. The first function in there is quite a long function as it handles setting the clock for all three hardware types. The LOCK is at the bottom of that function.JonAbbott wrote:In SWI_Funcs there's a TEMP R10-R12 at the top, but no LOCK to release them.
I thought that as that function was using STR to store things in ZP after setting the hardware then it ideally needed to use TEMP/LOCK?
Thanks for that, I'll give it a goJonAbbott wrote:Incidentally, if you're on a quest for bytes, you could recode SWI_Table along the lines of...
Paul
Re: AutoVIDC extASM issues
You can remove all the TEMP/LOCK from cmdEntry as they're not required, there's no auto-expansion that requires a temporary register.
For your byte quest, I spotted the following optimizations:
cmdEntry
For 4 bytes ... in .enableOC change:
to:
SWI_Funcs
For 4 bytes ... in ._SetAuxClock_SWI change:
to:
You could also reuse the SWI exit function to save 8 bytes each time. So one function has:
and the rest all use:
For your byte quest, I spotted the following optimizations:
cmdEntry
For 4 bytes ... in .enableOC change:
Code: Select all
ADR R0,enhancerlist
ADD R0, R0, #12
Code: Select all
ADR R0,enhancerlist + 12
For 4 bytes ... in ._SetAuxClock_SWI change:
Code: Select all
MOV R6, #4
MUL R6,R0,R6
Code: Select all
MOV R6,R0,LSL#2
Code: Select all
.SWI_exit
TEQ PC, PC
MOVEQ PC, R14
MOVS PC, R14
Code: Select all
B SWI_exit
Re: AutoVIDC extASM issues
I must have an old make file.PaulV wrote:But it does in the make file. I'm now officially confused! Were you looking in the file itself?
Turn Summary off in the extASM options, you'll see where you need TEMP/LOCK as it will say "Auto-expansion, using stacked register (Load/Store), 12 bytes"PaulV wrote:I thought that as that function was using STR to store things in ZP after setting the hardware then it ideally needed to use TEMP/LOCK?
Re: AutoVIDC extASM issues
Some other bytes you can get back:
SWI_Funcs
In .get_NextClocktoCheck change:
to:
After making all the changes I've mentioned and removing all TEMP/LOCK (none were required) it takes 23 passes (11 with shrink off) to compile and comes out at 7272 bytes. I've put a copy on the FTP site.
How do I test it? What am I looking to see broken?
SWI_Funcs
In .get_NextClocktoCheck change:
Code: Select all
ADD R2, R2,#4
LDR R1,[R2]
Code: Select all
LDR R1,[R2,#4]!
How do I test it? What am I looking to see broken?