Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-801099 ] ASX8051 bit handling insufficient and broken
|
From: SourceForge.net <no...@so...> - 2005-09-03 21:40:23
|
Bugs item #801099, was opened at 2003-09-05 15:55 Message generated for change (Comment added) made by ppisa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=801099&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msc51(8051) target Group: fixed >Status: Open Resolution: Fixed Priority: 5 Submitted By: Pavel Pisa (ppisa) Assigned to: Maarten Brock (maartenbrock) Summary: ASX8051 bit handling insufficient and broken Initial Comment: ASX8051 cannot handle common MCS51 bit syntax and even worse, sometimes silly substitute bit address 0 instead of assembler or linker error. Common code for A51 SER___C SEGMENT CODE SER___B SEGMENT DATA BITADDRESSABLE RSEG SER___B uL_FLG: DS 1 uLF_ER0 BIT uL_FLG.0 uLF_ER1 BIT uL_FLG.1 uLF_ERR BIT uL_FLG.2 ... RSEG SER___C ... JNB uLF_ERR,... ... This cannot be reasonably written in ASX8051, only alternative is something like next code (result of my SED A51 to ASX51 80 lines script) .area UL_BSEG (ABS,DATA,CON) ;ser___b .org 0x20 ul_bseg_s: .org 0x24 ul_flg: .ds 1 ulf_er0=((ul_flg-ul_bseg_s)*8)+0 ulf_er1=((ul_flg-ul_bseg_s)*8)+1 ulf_err=((ul_flg-ul_bseg_s)*8)+2 ... The lack of byte+offset=>bit relocation record in REL is bad, but next case is even worse. Original code ; Message status byte in XDATA message FIFO head uLBF_NORE EQU 040H ; Do not try to repeat if error occurs uLBF_NOREb EQU 6 uLBF_TAIL EQU 020H ; Message has tail frame uLBF_TAILb EQU 5 uLBF_REC EQU 010H ; Request receiption of block uLBF_RECb EQU 4 uLBF_FAIL EQU 008H ; Message cannot be send - error uLBF_PROC EQU 004H ; Message succesfull send uLBF_AAP EQU 003H ; Request imediate proccessing of frame by receiver station with acknowledge uLBF_PRQ EQU 002H ; Request imediate proccessing of frame by receiver station uLBF_ARQ EQU 001H ; Request imediate acknowledge by receiving station uLBF_END EQU 000H ; No acknowledge or processing request ... MOV C,ACC.uLBF_TAILb I have tried in ASX8051 ; Message status byte in XDATA message FIFO head ulbf_nore = 0x040 ; do not try to repeat if error occurs ulbf_noreb = 6 ulbf_tail = 0x020 ; message has tail frame ulbf_tailb = 5 ulbf_rec = 0x010 ; request receiption of block ulbf_recb = 4 ulbf_fail = 0x008 ; message cannot be send - error ulbf_proc = 0x004 ; message succesfull send ulbf_aap = 0x003 ; request imediate proccessing of frame by receiver station with acknowledge ulbf_prq = 0x002 ; request imediate proccessing of frame by receiver station ulbf_arq = 0x001 ; request imediate acknowledge by receiving station ulbf_end = 0x000 ; no acknowledge or processing request ... 070C A2 00 1417 mov c,acc.ulbf_tailb acc.ulbf_tailb **** X No warning, no error, many hours of locating strange behavior of complex interrupt driven state automata dependent dependent on combination of background task printf and other commands. OK, I understand, that first case is more problematic and can live with it for some time. I have first noticed it in SDCC discussion years ago, but there was no reaction. I have dared to try to port my code to SDCC now, because it is getting to be usable. But for the second case, there should be at least error report or better support added into ASX8051. There is simple relation for bit (bitnr) of data byte (daddr) and corresponding bitaddress (baddr) for MCS8051 int data2bit(int daddr, int bitnr) { if(bitnr>7) return -1; if((daddr>0x20)&&(daddr<0x30)){ return (daddr-0x20)*8+bitnr; }else if((daddr>0x80)&&!(daddr&0x7)){ return (daddr)+bitnr; } return -1; } If this is done this way all these nonsense table entries could be deleted from ASX8051 binary. {"SCON.0", 0x0098}, {"SCON.1", 0x0099}, {"SCON.2", 0x009A}, {"SCON.3", 0x009B}, {"SCON.4", 0x009C}, {"SCON.5", 0x009D}, {"SCON.6", 0x009E}, {"SCON.7", 0x009F}, ... {"scon.0", 0x0098}, {"scon.1", 0x0099}, {"scon.2", 0x009A}, {"scon.3", 0x009B}, {"scon.4", 0x009C}, {"scon.5", 0x009D}, {"scon.6", 0x009E}, {"scon.7", 0x009F}, They are bad, because they are hardwired for some specific target. What do about other targets (for example TI MSC1210 scon0.0, scon0.1,scon0.2,...,scon1.0,scon1.1,... . If somebody, who knows ASX can send me advice I try to redo this. The decision about future REL handling of the case 1 would be nice too. ---------------------------------------------------------------------- >Comment By: Pavel Pisa (ppisa) Date: 2005-09-03 23:40 Message: Logged In: YES user_id=523128 Thanks much to you, Maarten, this is great help and feature. I have tested current CVS SDCC sources (2.5.3+/-) today, generated code has been correect and USB to uLan converter works as expected. I have modified A51 to ASX51 conversion script (a51toasx.sh) to utilize provided feature. Our code and scripts are in SF uLan CVS. Best wishes Pavel ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2005-09-03 13:16 Message: Logged In: YES user_id=888171 Pavel, ASX8051 now has limited support for bit addressing in bytes with [ ]. F.e. ACC[0] accesses bit 0 of the accumulator. If you want to put a byte in the bit addressable memory space you can put it in BSEG_BYTES. Have a look at what SDCC 2.5.3 generates for bit parameters/local variables in reentrant functions. I hope this solves your problem, otherwise please respond within 14 days. Greets, Maarten ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2005-03-21 18:05 Message: Logged In: YES user_id=888171 I'm working on this, but that will not make it into the 2.5.0 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=801099&group_id=599 |