@ Terry..... SX/B 14 Broken?/ Not Understood?
pjv
Posts: 1,903
Hi Terry;
I'm trying SX/B version 14, and now my subs which were previously working won't compile. Perhaps I'm just not using the new features properly, but I believe the (optional?) word/byte modifiers for passing variables would be done in the sub definition. I use a lot of assembly subs and prefacing them with the modifiers does not work.
Am I wrong, and·must the modifiers be used in every instance the sub is called? If that is the case, then I think we may have gone a step backwards in utility as that becomes very verbose.
I was happy with the WCON construct of version 13. that is what my present code now uses, and it works well.
Mybe I'm not understanding something??
Cheers,
Peter (pjv)
Post Edited (pjv) : 2/25/2009 5:49:27 AM GMT
I'm trying SX/B version 14, and now my subs which were previously working won't compile. Perhaps I'm just not using the new features properly, but I believe the (optional?) word/byte modifiers for passing variables would be done in the sub definition. I use a lot of assembly subs and prefacing them with the modifiers does not work.
Am I wrong, and·must the modifiers be used in every instance the sub is called? If that is the case, then I think we may have gone a step backwards in utility as that becomes very verbose.
I was happy with the WCON construct of version 13. that is what my present code now uses, and it works well.
Mybe I'm not understanding something??
Cheers,
Peter (pjv)
Post Edited (pjv) : 2/25/2009 5:49:27 AM GMT
Comments
I'm also wondering how to properly define a function that returns something but expects nothing, e.g.:
RX_BYTE FUNC 1, 0
is how I used to do it. This worked in xx.13:
RX_BYTE FUNC 1, 0, 0, Byte
... but doesn't work in xx.14. What is the proper way to use the new syntax with this type of function?
[noparse][[/noparse]Edit] Even original-style definitions don't work in .14 (maybe that's what Peter meant).
Post Edited (JonnyMac) : 2/25/2009 7:26:44 AM GMT
Okay, I'll check it out. I completly changed the code that parses the parameters, so I probably have something messed up in there.
Any more examples that don't work ? It will help me make sure it's right.
[noparse][[/noparse]EDIT] Okay I found a problem (hopefully THE problem) the compiler is thinking there is 1 parameter when there is zero. So that's why the "Invalid Number of Paramters" error. I will fix this in a jiffy and post version 15. Peter, let me know if this clears up the issues you are having.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...
Post Edited (Bean (Hitt Consulting)) : 2/25/2009 12:59:11 PM GMT
[noparse][[/noparse]Edit] Okay, a bigger program seems to be working fine. Just a clarification on the "What's New" information: __PARAMCNT is only used when the sub or func allows a variable number of parameters; when the parameter count is fixed __PARAMCNT is not modified before the call hence is not useful (or needed) by the sub or func.
Post Edited (JonnyMac) : 2/25/2009 3:24:57 PM GMT
Peter, let me know if 15 fixes your issues also.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...
·
With version 15, I still can't get it to go. Here are my details:
FReportTimer con $0403 [url=mailto:'@3/4]'@3/4[/url] . . WriteFRAM SUB 4 . . WriteFram FReportTimer, @ReportTimer, 3 'THIS THROWS AN "INVALID NUMBER OF PARAMETERS" ERROR,whether the next line here specifying the size of each parameter is included or not . . {WriteFRAM: sub word, byte, byte} 'adding or deleting this line still will not copile ASM ;Param1 = byte addr in page; Param2 = Page address; Param3 = ram source address; Param4 = qty to read WriteFRAMa mov w,#%1010_0000 ;write FRAM command skip ; WriteRTC mov w,#%1101_0000 ;write RTC command setb DC ;also send byte address from Param1 call @__SendCommand ;output WRITE command with page address and byte address to I2C WritI2CLoop mov fsr,__Param3 ;point to source data mov __Param5,ind ;transfer to the shifter mov fsr,#$10 ;restore to SX/B running half call @__Param5ToI2C ;shift it out inc __Param3 ;next ram location decsz __Param4 ;decrement loop counter jmp @WritI2CLoop ; call @__StopI2C ; mov fsr,#$10 ; retp ; ENDASM ; {endsub} 'this line is included when the parameter specification line is included WriteFram 0, FReportTimer, @ReportTimer, 3 ' adding the dummy zero parameter with no type specifiers allows the sub to compileVersion 13 and not having any parameter type definitions (I mean the first line defining the sub) compiled OK.
With version 14 or 15, and using the 16 bit defined constant FReportTimer, it will not compile.
If I add an 8 bit·dummy parameter (the 0 in this case) it will compile.
It appears that it is treating the 16 bit constant as a single 8 bit parameter instead of two eight bit parameters.
When I substitute the 16 bit parameter FReportTimer·defined with a constant defined using the new WCONST construct, then it will compile.
I know my explanation and examples are a little convoluted, but I hope this helps. I can spend more time creating scenarios if you need it.
Also, for clarity, I think it would be good if we could use some terminology that clearly specifies whether· 8 bit, 16 bit, 24 bit and 32 bit constants all are 1 parameter, or 1,2,3,4 parameters. The line
·
····· WriteFram FReportTimer, @ReportTimer, 3
looks like 3 parameters (or 3 place holders), but with FReportTimer being 16 bits, it is actually 4 bytes that are enumerated.
Cheers,
Peter (pjv)
Okay, I see the problem. The WORD constant is only being counted as 1 bytes (even though it is two).
I have fixed that and posted version 16.
Also the parameter specifiers go in the SUB or FUNC declaration, as in:
· Let me know if 16 fixes the issue.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...
·
YOU'RE THE MAN!
That fixed it, many thanks.
Cheers,
Peter (pjv)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John J. Couture
San Diego Miramar College