Post by thread:CVASM16

I just got a Clear View Mathias at work. Now, I know that there are a number of CVM users out there, and I was wondering if I should take advantage of the assembler that comes with it. So I thought that I'd ask: * How many of y'all use the CVASM16 assembler on a regular basis? * If you do, what are the advantages/disadvantages? Do you have trouble getting code samples? CVASM16 takes MPASM instructions but places restrictions on them; if you feed it MPASM code, do you find that you frequently have to hand process the code before you use it, or does most code work with minimal tweaking? Do you find that if you modify code for CVASM16 and then try to take it back to MPASM that you have to do any back-porting? If you stick to the CV-specific "8051-like" instructions, again -- are code samples rare? Do you have much trouble porting code samples from other 8051 chips? * If you've considered/tried CVASM16 but stuck with MPASM (if you just went to using C or BASIC or something that's another matter), what shortcomings of CVASM16/advantages of MPASM led you to that decicsion? If you use MPASM on the CVM, do you find this putting you at any sort of significant disadvantage? I've been using MPASM for some stuff, and for some stuff (including a commercial package -- emWare -- that comes as MPASM source) I'll probably have to continue using MPASM for some time. But I was just trying to decide if it was worth the trouble to learn CVASM16 as well. TIA, --Bob -- ============================================================ Bob Drzyzgula It's not a problem spam_OUTbobTakeThisOuTdrzyzgula.org until something bad happens ============================================================

Hello All, I definitely use CVASM16 and its predecessor the SPASM (the both are virtually identical; the former supports more processor types, the latter cooperates with PSIM, which is one of the most fine PIC emulators ever). Advantages of them: - small (below 20 kByte) - robust (did not detect any (!) crash, or misbehavior) - DOS-based (a high-rated criteria for me) - supports MPASM, extended MPASM and Parallax mnemonics - has a good built-in arithmetics - incredible fast - supports local labels - very fine feature! - one can equates single bits (e. g. LED EQU RA.3) - all standard register and bit names are known and supported (e. g. GIE, TMR0) w/o any includes. Disadvantages: - does not support macros and conditional compile - the constant format differs from that of Microchip (no problem for me as SPASM is the primary choice) - the arithmetics is a bit strange (exactly like a calculator: no algebraic logic or parentheses, only strict left-to-right evaluation) - the list file is slightly less informative than that of MPASM All the code samples compile if you accept the differences written in disadvantages. However, there are a lot of 8051-like samples (see Scott), and it is simply clearer for me. Take e. g. the CJAE instruction... Such way, the point #3 does not fit for me, rather the opposite. I must say I'm happy with it and use MPASM only if I badly need it. This is my $0.02 word. Imre On Thu, 6 May 1999, Bob Drzyzgula wrote: {Quote hidden}> I just got a Clear View Mathias at work. Now, I know > that there are a number of CVM users out there, and I was > wondering if I should take advantage of the assembler > that comes with it. So I thought that I'd ask: > > * How many of y'all use the CVASM16 assembler on > a regular basis? > > * If you do, what are the advantages/disadvantages? > Do you have trouble getting code samples? CVASM16 > takes MPASM instructions but places restrictions > on them; if you feed it MPASM code, do you find > that you frequently have to hand process the code > before you use it, or does most code work with > minimal tweaking? Do you find that if you modify > code for CVASM16 and then try to take it back to > MPASM that you have to do any back-porting? If > you stick to the CV-specific "8051-like" instructions, > again -- are code samples rare? Do you have much > trouble porting code samples from other 8051 chips? > > * If you've considered/tried CVASM16 but stuck with > MPASM (if you just went to using C or BASIC or > something that's another matter), what shortcomings > of CVASM16/advantages of MPASM led you to that > decicsion? If you use MPASM on the CVM, do > you find this putting you at any sort of > significant disadvantage? > > I've been using MPASM for some stuff, and for some > stuff (including a commercial package -- emWare -- > that comes as MPASM source) I'll probably have to > continue using MPASM for some time. But I was just > trying to decide if it was worth the trouble to > learn CVASM16 as well. > > TIA, > --Bob > > -- > ============================================================ > Bob Drzyzgula It's not a problem > .....bobKILLspam@spam@drzyzgula.org until something bad happens > ============================================================ > >

> * How many of y'all use the CVASM16 assembler on > a regular basis? Yo! Although I use the HiTech one more and more (part of the C package). > * If you do, what are the advantages/disadvantages? I use Microchip mnemonics. The advantage is that it supports both Parallax and Microchips. > on them; if you feed it MPASM code, do you find > that you frequently have to hand process the code > before you use it, or does most code work with If macros or conditionals are used, then yes, you need to work it over first. Going in the other direction, though, isn't that bad since you can use #define's to get the Microchip asm to support the CV's bit definitions, etc. > minimal tweaking? Do you find that if you modify > code for CVASM16 and then try to take it back to > MPASM that you have to do any back-porting? If See above. > you stick to the CV-specific "8051-like" instructions, > again -- are code samples rare? Do you have much > trouble porting code samples from other 8051 chips? We have one guy who came here with only 8051 background. Many of his code library routines worked as-is or with minimal change. > decicsion? If you use MPASM on the CVM, do > you find this putting you at any sort of > significant disadvantage? It shouldn't. I've used all three assemblers here, and CVASM and MPASM are both fine. >I've been using MPASM for some stuff, and for some >stuff (including a commercial package -- emWare -- >that comes as MPASM source) I'll probably have to >continue using MPASM for some time. But I was just >trying to decide if it was worth the trouble to >learn CVASM16 as well. If you're already using MPASM, you shouldn't change. (Sorry, Jerry). Not until CVASM supports macros and conditionals (which I've been asking for for 4 years at least, even volunteering to add them to the assembler gratis but was always turned down.) Andy ================================================================== Montana Design Tech Support - http://www.montanadesign.com ==================================================================

Bob, I started with SPASM about five years ago and then moved to CVASM. Dr. Imre Bartfai provided a good description in his earlier message. I prefer the Intel-style Parallax syntax but I would caution anyone moving to CVASM (formerly SPASM) to also have a good knowledge of the native Microchip syntax to get the most out of the assembler. The only thing I miss is a macro capability. Most instructions are really macros of native code and the documentation shows exactly what each instruction generates. You have direct equivalents of all of the native set as well as powerful extensions. I find it much more intuitive. Some examples: Compare File Register Fr1 to Fr2 and Jump if Above or Equal CJAE Fr1,Fr2,label Which translates to: MOVF Fr2,0 SUBWF Fr1,0 BTFSC 3,0 GOTO label One of my favorites is the way it handles LCALL so you don't have to mess with PCLATH: LCALL A_Routine_In_Any_Code_Page LSET $ ; Restore PCLATH The assembler, depending on device size, will insert 0-2 BCF/BSF instructions. As far as converting native syntax, the main issues are the differences in the radix and local label syntax. There are a few other things but I've never had a problem converting native code with trivial changes in syntax. By "other things" I'm referring to the way the C, Z flags are defined. In MPASM, they are literals. In CVASM they are STATUS.0 etc. So when you run across something like: BTFSC STATUS,C You can either use: BTFSC STATUS,0 ; Native syntax. BTFSC 3,0 ; same same... JNC ; CVASM equivalent One final thing is to note how the native instructions are qualified by a "0" or "1" (W or F). Normally, CVASM will have no problem with it but if you translate it, be sure to select the equivalent instruction. This is fairly easy but there are a few instructions that may not be so obvious. For example: swapf Register,1 = SWAP Register swapf Register,0 = MOV W,<>Register Again, this is well documented but I wish they would continue to provide the Readme.txt file that Parallax always supplied with SPASM and TDE provided with earlier versions of CVASM. This listed all the device equates as well as the CVASM and the Microchip instruction set with their equivalents. This made it easy to look at a native instruction and see the CVASM equivalent. (Jerry, any word on this?). - Tom At 09:59 PM 5/6/99 -0400, Bob Drzyzgula wrote: {Quote hidden}>I just got a Clear View Mathias at work. Now, I know >that there are a number of CVM users out there, and I was >wondering if I should take advantage of the assembler >that comes with it. So I thought that I'd ask: > > * How many of y'all use the CVASM16 assembler on > a regular basis? > > * If you do, what are the advantages/disadvantages? > Do you have trouble getting code samples? CVASM16 > takes MPASM instructions but places restrictions > on them; if you feed it MPASM code, do you find > that you frequently have to hand process the code > before you use it, or does most code work with > minimal tweaking? Do you find that if you modify > code for CVASM16 and then try to take it back to > MPASM that you have to do any back-porting? If > you stick to the CV-specific "8051-like" instructions, > again -- are code samples rare? Do you have much > trouble porting code samples from other 8051 chips? > > * If you've considered/tried CVASM16 but stuck with > MPASM (if you just went to using C or BASIC or > something that's another matter), what shortcomings > of CVASM16/advantages of MPASM led you to that > decicsion? If you use MPASM on the CVM, do > you find this putting you at any sort of > significant disadvantage? > >I've been using MPASM for some stuff, and for some >stuff (including a commercial package -- emWare -- >that comes as MPASM source) I'll probably have to >continue using MPASM for some time. But I was just >trying to decide if it was worth the trouble to >learn CVASM16 as well. > >TIA, >--Bob

> > Again, this is well documented but I wish they would continue to provide >the Readme.txt file that Parallax always supplied with SPASM and TDE >provided with earlier versions of CVASM. This listed all the device >equates as well as the CVASM and the Microchip instruction set with their >equivalents. This made it easy to look at a native instruction and see the >CVASM equivalent. (Jerry, any word on this?). > > - Tom > Well.... We put the CVASM16 and native Microchip instruction set references in the manual, on line from within TDE and on the disk in PDF format. These are also available on our web pages and our CDROM. The most recent release of CVASM16 included a new command-line switch '/d' that added a complete symbol table dump to your LIST file. This lets you see all of the pre-defined symbols as well as any used in the current program. This is not quit as convenient as a pre-printed references, but is guaranteed to be up-to-date. This list is the exact symbol table the assembler is using. If you want a simple list of the pre-defined symbols for a particular processor, simple create a 1 line program containing the device directive and assemble it with the /d option. Print the list file and you have a cross-reference. Jerry Merrill jerrymKILLspamtech-tools.com http://www.tech-tools.com FAX: (972) 494-5814 VOICE:(972) 272-9392 TechTools PO Box 462101 Garland, TX 75046-2101

Jerry, thanks. I think the new docs are great and I know about the "/D" option. What I was referring to is the old cross-reference where you could look up a Microchip instruction and see the Parallax/CVASM equivalent. While the Microchip equivalent is listed for all the CVASM instructions, the former makes it easier when converting native code to CVASM. An example I mentioned earlier is swapf fr,1 and swapf fr,0. While it's easy to find SWAP, it's not very obvious that swapf fr,0 is MOV W,<>fr. I think it would be useful to add that to the docs. It's only a page or two. - Tom At 03:48 PM 5/10/99 -0500, Jerry Merrill wrote: {Quote hidden}>> >> Again, this is well documented but I wish they would continue to provide >>the Readme.txt file that Parallax always supplied with SPASM and TDE >>provided with earlier versions of CVASM. This listed all the device >>equates as well as the CVASM and the Microchip instruction set with their >>equivalents. This made it easy to look at a native instruction and see the >>CVASM equivalent. (Jerry, any word on this?). >> >> - Tom >> > >Well.... >We put the CVASM16 and native Microchip instruction set references in the >manual, on line from within TDE and on the disk in PDF format. These are >also available on our web pages and our CDROM. > >The most recent release of CVASM16 included a new command-line switch '/d' >that added a complete symbol table dump to your LIST file. This lets you >see all of the pre-defined symbols as well as any used in the current >program. This is not quit as convenient as a pre-printed references, but >is guaranteed to be up-to-date. This list is the exact symbol table the >assembler is using. > >If you want a simple list of the pre-defined symbols for a particular >processor, simple create a 1 line program containing the device directive >and assemble it with the /d option. Print the list file and you have a >cross-reference. > > >Jerry Merrill > >.....jerrymKILLspam.....tech-tools.com >http://www.tech-tools.com >FAX: (972) 494-5814 >VOICE:(972) 272-9392 >TechTools >PO Box 462101 >Garland, TX 75046-2101 > >

At 03:40 AM 5/11/99 -0700, you wrote: > Jerry, thanks. I think the new docs are great and I know about the "/D" >option. What I was referring to is the old cross-reference where you could >look up a Microchip instruction and see the Parallax/CVASM equivalent. >While the Microchip equivalent is listed for all the CVASM instructions, >the former makes it easier when converting native code to CVASM. An example >I mentioned earlier is swapf fr,1 and swapf fr,0. While it's easy to find >SWAP, it's not very obvious that swapf fr,0 is MOV W,<>fr. I think it would >be useful to add that to the docs. It's only a page or two. > > - Tom > I actually did not realize such a 'reverse' reference was ever done, but it makes good sense. Good point and good timing. We are reworking the manual and help files now. I will see that it is included. Jerry Merrill EraseMEjerrymspam_OUTTakeThisOuTtech-tools.com http://www.tech-tools.com FAX: (972) 494-5814 VOICE:(972) 272-9392 TechTools PO Box 462101 Garland, TX 75046-2101

Jerry, the last time I saw it was in the the TechTools PIC16Cxx Assembler v5.1 release. I have it under "CVASM16.txt" but it may have been renamed from a ReadMe.txt file. The text file is 120 characters wide. Before the pre-defined symbols and device equates, there were two lists. The first is the TechTools Instruction Set and the second is the Microchip Instruction Set. Both lists have the same format: Instruction, Words, Flags, W Used, Description, Instruction Equivalent. I'd recommend including both lists as it makes it very easy to convert native syntax. I keep a copy of both lists at my side when I'm programming. If you want, I can send the text file. Thanks, - Tom At 08:46 AM 5/11/99 -0500, Jerry Merrill wrote: {Quote hidden}>At 03:40 AM 5/11/99 -0700, Tom Handley wrote: >> Jerry, thanks. I think the new docs are great and I know about the "/D" >>option. What I was referring to is the old cross-reference where you could >>look up a Microchip instruction and see the Parallax/CVASM equivalent. >>While the Microchip equivalent is listed for all the CVASM instructions, >>the former makes it easier when converting native code to CVASM. An example >>I mentioned earlier is swapf fr,1 and swapf fr,0. While it's easy to find >>SWAP, it's not very obvious that swapf fr,0 is MOV W,<>fr. I think it would >>be useful to add that to the docs. It's only a page or two. >> >> - Tom >> > >I actually did not realize such a 'reverse' reference was ever done, but it >makes good sense. > >Good point and good timing. We are reworking the manual and help files >now. I will see that it is included. > > >Jerry Merrill > >jerrymspam_OUTtech-tools.com >http://www.tech-tools.com >FAX: (972) 494-5814 >VOICE:(972) 272-9392 >TechTools >PO Box 462101 >Garland, TX 75046-2101

At 03:48 AM 5/12/99 -0700, you wrote: > Jerry, the last time I saw it was in the the TechTools PIC16Cxx Assembler >v5.1 release. I have it under "CVASM16.txt" but it may have been renamed >from a ReadMe.txt file. The text file is 120 characters wide. Before the >pre-defined symbols and device equates, there were two lists. The first is >the TechTools Instruction Set and the second is the Microchip Instruction >Set. Both lists have the same format: > > Instruction, Words, Flags, W Used, Description, Instruction Equivalent. > > I'd recommend including both lists as it makes it very easy to convert >native syntax. I keep a copy of both lists at my side when I'm programming. >If you want, I can send the text file. > > Thanks, > > - Tom > No need to send it. I pulled it from an archive and found the section you reference. I'd forgotten about that part of the file. It _IS_ indeed a good reference. We will put both tables into the manual and on-line help. Thanks for the recommendation! Jerry Merrill @spam@jerrymKILLspamtech-tools.com http://www.tech-tools.com FAX: (972) 494-5814 VOICE:(972) 272-9392 TechTools PO Box 462101 Garland, TX 75046-2101

Jerry, I have another suggestion for your documentation update. It would help to add a short section on converting Microchip syntax to CVASM. The obvious difference is the radix syntax. The Microchip conversion list already covers fr and fr,W as well as the special instructions such as SKPC. You could put in a short note about macros and the need to `unroll' them. One problem that shows up a lot is operations using the STATUS register as in the following example: Problem: Fix: BTFSS STATUS,C -> BTFSS C or BTFSS STATUS,0 BTFSS STATUS,DC -> BTFSS DC or BTFSS STATUS,1 BTFSS STATUS,Z -> BTFSS Z or BTFSS STATUS,2 While CVASM will pass STATUS,C the other two will generate a Bit range error. The fact that it passes C is a minor `quirk'. C, DC, and Z are defined as Bit definitions (STATUS.0/1/2) as opposed to literals. What would really be nice is to have the assembler recognize and convert the STATUS,C/DC/Z syntax. The above should cover the majority of problems. You might want to just add a few paragraphs below the syntax conversion lists. This would help folks that have had reservations about using CVASM with all the native syntax examples. - Tom

At 02:47 PM 5/13/99 -0700, you wrote: {Quote hidden}> Jerry, I have another suggestion for your documentation update. It would >help to add a short section on converting Microchip syntax to CVASM. The >obvious difference is the radix syntax. The Microchip conversion list >already covers fr and fr,W as well as the special instructions such as SKPC. >You could put in a short note about macros and the need to `unroll' them. >One problem that shows up a lot is operations using the STATUS register as >in the following example: > > Problem: Fix: > BTFSS STATUS,C -> BTFSS C or BTFSS STATUS,0 > BTFSS STATUS,DC -> BTFSS DC or BTFSS STATUS,1 > BTFSS STATUS,Z -> BTFSS Z or BTFSS STATUS,2 > > While CVASM will pass STATUS,C the other two will generate a Bit range >error. The fact that it passes C is a minor `quirk'. C, DC, and Z are >defined as Bit definitions (STATUS.0/1/2) as opposed to literals. What >would really be nice is to have the assembler recognize and convert the >STATUS,C/DC/Z syntax. > > The above should cover the majority of problems. You might want to just >add a few paragraphs below the syntax conversion lists. This would help >folks that have had reservations about using CVASM with all the native >syntax examples. > > - Tom > Good point. Microchip uses Literals (0-7) to define the bit _NUMBER_ within a register for all pre-defined bits. This makes sense because they do not have atrue BIT variable type. Thier syntax uses 'reg,bit_num'. CVASM uses actual bit variables with fully encode the actual bit address. The STATUS register bits are often used as you describe and therefor occur more often in source files, but this syntactical difference will show up with most bit operations. We have been kicking around the idea of a MPASM-2-CVASM conversion program that would expand macros, resolve conditionals and convert radix, bit notations and any other syntax. It doesn't appear to be too difficult; just too many good ideas.....not enough time. Anybody up to the challenge? Jerry Merrill KILLspamjerrymKILLspamtech-tools.com http://www.tech-tools.com FAX: (972) 494-5814 VOICE:(972) 272-9392 TechTools PO Box 462101 Garland, TX 75046-2101

At 12:30 PM 5/14/99 -0400, you wrote: >what is CVASM? > CVASM is our PIC assembler. It accepts the Parallax instruction set as well as the original Microchip instructions. The Parallax instruction set is much easier to read & remember. It uses 8051-like mnemonics. CVASM assembles code for all current 12 and 14 bit PIC devices. CVASM accepts MPASM mnemonics but does NOT directly assemble MPASM source code without some hand conversions. Primarily, CVASM does not support MACROs, CONDITIONALS or the MPASM directives. As Tom pointed out, BITS are defined as literal bit NUMBERs in MPASM and as actual bit ADDRESSES in CVASM. CVASM is included with all of our PIC products or you can download it from our web pages. Jerry Merrill RemoveMEjerrymTakeThisOuTtech-tools.com http://www.tech-tools.com FAX: (972) 494-5814 VOICE:(972) 272-9392 TechTools PO Box 462101 Garland, TX 75046-2101

Although the inclusion of macro/conditional capability inside CVASM would be the best solution -- then you could use the macros for the Paralax mnemonics as well -- perhaps a good start on a translator utility might be had by using the yacc/lex parsing engine in gpasm...? Just a thought. --Bob On Fri, May 14, 1999 at 12:15:15PM -0400, Andy Kunz wrote: {Quote hidden}> >We have been kicking around the idea of a MPASM-2-CVASM conversion program > >that would expand macros, resolve conditionals and convert radix, bit > >notations and any other syntax. It doesn't appear to be too difficult; > >just too many good ideas.....not enough time. > > > >Anybody up to the challenge? > > Jerry, > > A long time ago I volunteered to add macros and conditionals to CVASM for > free, and nobody ever got back to me. The offer still stands. > > Andy > > > ================================================================== > Montana Design Tech Support - http://www.montanadesign.com > ================================================================== -- ============================================================ Bob Drzyzgula It's not a problem spamBeGonebobspamBeGonedrzyzgula.org until something bad happens ============================================================

> >A long time ago I volunteered to add macros and conditionals to CVASM for >free, and nobody ever got back to me. The offer still stands. > >Andy > > >================================================================== > Montana Design Tech Support - http://www.montanadesign.com >================================================================== I appreciate your offer but I would have some reservations. I would be concerned about ripple effects. TDE derives its debugging information from the LIST file generated by CVASM. Macros would affect the list file and thereby affect TDE's ability to parse the file. Any CVASM changes that affect its list file would have to be designed to avoid breaking TDE or would have to be released in conjunction with a TDE update, unless that change included generating a COD file as well. I expect generating a COD file is more work than adding the MACROs and conditionals. My point is that updating CVASM itself is only one part of a larger effort. There truly is no free lunch. I expect Parallax was thinking similar things when you made them this offer. Jerry Merrill TakeThisOuTjerrymEraseMEspam_OUTtech-tools.com http://www.tech-tools.com FAX: (972) 494-5814 VOICE:(972) 272-9392 TechTools PO Box 462101 Garland, TX 75046-2101

Jerry, the last time I talked to John at Parallax, they had made some progress on SwapCode but obviously they don't have time to work with it. I've been wanting to write a converter for several years but like everyone else, `my plate is full'... I may take another look at it. - Tom At 08:32 AM 5/14/99 -0500, Jerry Merrill wrote: {Quote hidden}> >We have been kicking around the idea of a MPASM-2-CVASM conversion program >that would expand macros, resolve conditionals and convert radix, bit >notations and any other syntax. It doesn't appear to be too difficult; >just too many good ideas.....not enough time. > >Anybody up to the challenge? > > >Jerry Merrill > >RemoveMEjerrymTakeThisOuTtech-tools.com >http://www.tech-tools.com >FAX: (972) 494-5814 >VOICE:(972) 272-9392 >TechTools >PO Box 462101 >Garland, TX 75046-2101

Bob, when Jerry brought this up the first thing that came to mind is yacc/lex. I've been away from UNIX for several years. Can you give me a pointer to the generic C code? I'm sure I can track it down but if you have a preference (you mentioned GPASM), I'd appreciate it. I'm not committing to this but I want to revisit the subject. I wasn't considering a `code converter', rather a `syntax modifier'. Consider an example where BIT2 is moved to BIT1 in register UBits. Then the Z flag is tested and a jump to Label1 occurs if False. Otherwise, the register Data is compared to the literal Limit and a jump to Label2 occurs if Data is above or equal to Limit. This provides a good idea of both the differences in syntax and the overall compatibility of MPASM and CVASM. A `code converter' would do the following: MPASM: CVASM: ------------------------------------------------------------------ Data EQU 0x20 Data = 20h UBits EQU 0x21 UBITS = 21h BIT1 EQU 1 BIT1 = UBits.1 BIT2 EQU 2 BIT2 = UBits.2 Limit EQU B'01010101' Limit = 01010101b BTFSS UBits,BIT2 MOVB BIT1,BIT2 BCF UBits,BIT1 BTFSC UBits,BIT2 BSF UBits,BIT1 BTFSS STATUS,Z SZ GOTO Label1 JMP Label1 MOVLW Limit CJAE Data,#Limit,Label2 SUBWF Data,W BTFSC STATUS,C GOTO Label2 A `syntax modifier' would do the following: MPASM: CVASM Compatible: ------------------------------------------------------------------ Data EQU 0x20 Data EQU 20h UBits EQU 0x21 UBits EQU 21h BIT1 EQU 1 BIT1 EQU 1 BIT2 EQU 2 BIT2 EQU 2 Limit EQU B'01010101' Limit EQU 01010101b BTFSS UBits,BIT2 BTFSS UBits,BIT2 BCF UBits,BIT1 BCF UBits,BIT1 BTFSC UBits,BIT2 BTFSC UBits,BIT2 BSF UBits,BIT1 BSF UBits,BIT1 BTFSS STATUS,Z BTFSS STATUS,2 GOTO Label1 GOTO Label1 MOVLW Limit MOVLW Limit SUBWF Data,W SUBWF Data,W BTFSC STATUS,C BTFSC STATUS,0 GOTO Label2 GOTO Label2 Even a `syntax modifier' would still be a challenge as you have to deal with MPASM's directives and conditionals as well as the macros, radix, etc. Normally, converting from MPASM to CVASM is fairly easy for most example code from Microchip and the public domain. - Tom At 03:31 PM 5/14/99 -0400, Bob Drzyzgula wrote: {Quote hidden}>Although the inclusion of macro/conditional capability inside >CVASM would be the best solution -- then you could use >the macros for the Paralax mnemonics as well -- perhaps a >good start on a translator utility might be had by >using the yacc/lex parsing engine in gpasm...? Just a >thought. > >--Bob >============================================================ >Bob Drzyzgula It's not a problem >bobEraseME.....drzyzgula.org until something bad happens >============================================================

Tom, Your point about the difference between "code conversion" and "syntax modification" is an excellent one; as is your example... the complexity required of a translator that could figure out that a variable EQU'd to "2" really ought to be defined as a bit address is nothing if not daunting, especially since there would be no guarantee that the variable EQU'd to "2" would be used only once, e.g.: Data EQU 0x20 UBits EQU 0x21 XBits EQU 0x22 BIT1 EQU 1 BIT2 EQU 2 Limit EQU B'01010101' BTFSS UBits,BIT1 BCF XBits,BIT1 BTFSC UBits,BIT2 BSF XBits,BIT2 BTFSS STATUS,Z GOTO Label1 MOVLW Limit SUBWF Data,W BTFSC STATUS,C GOTO Label2 Yeah, that's some really nasty code, but you kinda gotta plan for nasty code. :-( Gpasm is the GPL'd assembler for MPASM code, done mostly by James Bowman, and recently enhanced by Scott Dattalo and others to, among other things, generate .cod output. For more information, you probably want to browse around among the following links: http://reality.sgi.com/jamesb/gpasm/ interstice.com/~sdattalo/gnupic/gpsim.html http://reality.sgi.com/jamesb/gnupic/ Scott's gpasm distribution is more recent than what is on James' site; Scott has posted recently that he has not been able to contact James for some time. Scott of course is a frequent poster on this list and can give much better information on these issues than can I. But I'm guessing that a lot of the gnarly work you would be facing in defining the front end MPASM lexer/parser would be done for you; you could then focus on what to generate on the output side. BTW, here is a caution Scott sent me earlier: "gpasm actually handles macros separate from the lexer. There's a file called 'special.inc' that consists of the special/common macros like 'skpc'. It would be trivial to add paralax mnemonics as a set of macros to gpasm. OTOH, the logic for parsing macros IS part of the lexer/parser." His point about handling the paralax mnemonics is an interesting one. Clearly, in a syntax conversion approach as you suggest, you could pretty much pass paralax mnemonics through untouched. Thus, if you were to build a utility that could (a) convert MPASM syntax to CVASM syntax, (b) unroll MPASM macros and conditional, *and* (c) pass paralax syntax and mnemonics through unmolested, then you might well be able to make the first step of having general-purpose macro capability in CVASM. You should also be aware that all the gpasm stuff is GPL'd, which would make it pretty close to impossible to use the gpasm parser without your result being GPL'd as well. If you have been away from Unix for several years you may want to grab the Cygnus Cygwin distribution... see http://sourceware.cygnus.com/cygwin/ Beware, however, because gpasm does not yet compile under Cygwin (at least, I tried under NT and Cygwin b20 last week, and the compile hung up on a call to getopt). That was something I was thinking about working on; I may have some time this week to fool with it. But still, cygwin would give you a working, recent copy of yacc and lex (bison and flex, actually) without having to get access to a Unix/Linux machine. --Bob On Sat, May 15, 1999 at 04:36:31AM -0700, Tom Handley wrote: > Bob, when Jerry brought this up the first thing that came to mind is > yacc/lex. I've been away from UNIX for several years. Can you give me a > pointer to the generic C code? I'm sure I can track it down but if you have > a preference (you mentioned GPASM), I'd appreciate it. > ... > > Even a `syntax modifier' would still be a challenge as you have to deal > with MPASM's directives and conditionals as well as the macros, radix, etc. > Normally, converting from MPASM to CVASM is fairly easy for most example > code from Microchip and the public domain. > > - Tom -- ============================================================ Bob Drzyzgula It's not a problem EraseMEbobdrzyzgula.org until something bad happens ============================================================

Hi, a remark to this: the listing output of SPASM could be used by PSIM, but the listing output of CVASM not. I guess it depends on the listing header. Do intend TechTools to further develop also PSIM? I think Andy's offer is nice. I'd say the problem is more simple than it seems to be. It is not a huge task to write e. g. an AWK script which convert the new format (or whichever) listing to that required by TDE. I did a lot of this kind of stuff. Imre On Fri, 14 May 1999, Jerry Merrill wrote: {Quote hidden}> > > >A long time ago I volunteered to add macros and conditionals to CVASM for > >free, and nobody ever got back to me. The offer still stands. > > > >Andy > > > > > >================================================================== > > Montana Design Tech Support - http://www.montanadesign.com > >================================================================== > > I appreciate your offer but I would have some reservations. I would be > concerned about ripple effects. > > TDE derives its debugging information from the LIST file generated by > CVASM. Macros would affect the list file and thereby affect TDE's ability > to parse the file. > > Any CVASM changes that affect its list file would have to be designed to > avoid breaking TDE or would have to be released in conjunction with a TDE > update, unless that change included generating a COD file as well. I > expect generating a COD file is more work than adding the MACROs and > conditionals. > > My point is that updating CVASM itself is only one part of a larger effort. > There truly is no free lunch. I expect Parallax was thinking similar > things when you made them this offer. > > > > > Jerry Merrill > > RemoveMEjerrymEraseMEEraseMEtech-tools.com > http://www.tech-tools.com > FAX: (972) 494-5814 > VOICE:(972) 272-9392 > TechTools > PO Box 462101 > Garland, TX 75046-2101 > >

Hi, I agree. However, a short remark. Instead of SZ JMP Label1 one could write JNZ Label1 Imre On Sat, 15 May 1999, Tom Handley wrote: {Quote hidden}> Bob, when Jerry brought this up the first thing that came to mind is > yacc/lex. I've been away from UNIX for several years. Can you give me a > pointer to the generic C code? I'm sure I can track it down but if you have > a preference (you mentioned GPASM), I'd appreciate it. > > I'm not committing to this but I want to revisit the subject. I wasn't > considering a `code converter', rather a `syntax modifier'. Consider an > example where BIT2 is moved to BIT1 in register UBits. Then the Z flag is > tested and a jump to Label1 occurs if False. Otherwise, the register Data is > compared to the literal Limit and a jump to Label2 occurs if Data is above > or equal to Limit. This provides a good idea of both the differences in > syntax and the overall compatibility of MPASM and CVASM. > > A `code converter' would do the following: > > MPASM: CVASM: > ------------------------------------------------------------------ > Data EQU 0x20 Data = 20h > UBits EQU 0x21 UBITS = 21h > BIT1 EQU 1 BIT1 = UBits.1 > BIT2 EQU 2 BIT2 = UBits.2 > Limit EQU B'01010101' Limit = 01010101b > > > BTFSS UBits,BIT2 MOVB BIT1,BIT2 > BCF UBits,BIT1 > BTFSC UBits,BIT2 > BSF UBits,BIT1 > BTFSS STATUS,Z SZ > GOTO Label1 JMP Label1 > MOVLW Limit CJAE Data,#Limit,Label2 > SUBWF Data,W > BTFSC STATUS,C > GOTO Label2 > > A `syntax modifier' would do the following: > > MPASM: CVASM Compatible: > ------------------------------------------------------------------ > Data EQU 0x20 Data EQU 20h > UBits EQU 0x21 UBits EQU 21h > BIT1 EQU 1 BIT1 EQU 1 > BIT2 EQU 2 BIT2 EQU 2 > Limit EQU B'01010101' Limit EQU 01010101b > > BTFSS UBits,BIT2 BTFSS UBits,BIT2 > BCF UBits,BIT1 BCF UBits,BIT1 > BTFSC UBits,BIT2 BTFSC UBits,BIT2 > BSF UBits,BIT1 BSF UBits,BIT1 > BTFSS STATUS,Z BTFSS STATUS,2 > GOTO Label1 GOTO Label1 > MOVLW Limit MOVLW Limit > SUBWF Data,W SUBWF Data,W > BTFSC STATUS,C BTFSC STATUS,0 > GOTO Label2 GOTO Label2 > > Even a `syntax modifier' would still be a challenge as you have to deal > with MPASM's directives and conditionals as well as the macros, radix, etc. > Normally, converting from MPASM to CVASM is fairly easy for most example > code from Microchip and the public domain. > > - Tom > > At 03:31 PM 5/14/99 -0400, Bob Drzyzgula wrote: > >Although the inclusion of macro/conditional capability inside > >CVASM would be the best solution -- then you could use > >the macros for the Paralax mnemonics as well -- perhaps a > >good start on a translator utility might be had by > >using the yacc/lex parsing engine in gpasm...? Just a > >thought. > > > >--Bob > >============================================================ > >Bob Drzyzgula It's not a problem > >RemoveMEbobspam_OUTKILLspamdrzyzgula.org until something bad happens > >============================================================ > >

At 10:52 AM 5/15/99 +0200, you wrote: >Hi, >a remark to this: >the listing output of SPASM could be used by PSIM, but the listing output >of CVASM not. I guess it depends on the listing header. This is probably because we changed CVASM's list file format some time back to provide absolute register addresses for all defined symbols. Earlier versions only encoded the OFFSET within a bank, making it impossible for TDE to properly track variables in upper RAM banks. >Do intend TechTools to further develop also PSIM? > Unfortunately, TechTools does not have the source (or any rights) to PSIM. I do not think Parallax has the source either. I _THINK_ it was developed by a third party. >I think Andy's offer is nice. I'd say the problem is more simple than it >seems to be. It is not a huge task to write e. g. an AWK script which >convert the new format (or whichever) listing to that required by TDE. I >did a lot of this kind of stuff. >Imre > My biggest concern is MACROs. Currently, there is a 1 to 1 relationship between the SOURCE file and the LIST file. Parallax instructions are expanded ON A SINGLE line (and more specifically, within the HEX field on that line). The CVASM LIST PARSER within TDE expects to find 1 to 3 HEX words in this field that correspond to this instruction. Macros could/would expand to many more words of code; breaking the 1-to-1 relationship. I do not think it is possible to filter a MACRO EXPANDED list file into a format compatible with the existing parser routine. If such a filter IS possible, then TDE can easily accommodate it. We can add the post filter command to the make script. The parser _MAY_ accept multiple lines with the same line number. It certainly was not designed with this in mind, but it occurs to me it might still build a consistent database. In that case, a macro could be expanded directly in-line and no post filter would be needed. I will take a look at the parser code in the next few days and see if this has a chance of working. Jerry Merrill RemoveMEjerrymTakeThisOuTspamtech-tools.com http://www.tech-tools.com FAX: (972) 494-5814 VOICE:(972) 272-9392 TechTools PO Box 462101 Garland, TX 75046-2101

At 08:47 AM 5/17/99 -0500, Jerry Merrill wrote: >At 10:52 AM 5/15/99 +0200, Dr. Imre Bartfai wrote: >>Hi, >>a remark to this: >>the listing output of SPASM could be used by PSIM, but the listing output >>of CVASM not. I guess it depends on the listing header. > >This is probably because we changed CVASM's list file format some time back >to provide absolute register addresses for all defined symbols. Earlier >versions only encoded the OFFSET within a bank, making it impossible for >TDE to properly track variables in upper RAM banks. This was the first major change from SPASM. You use to have to originate registers at the same bank 0 address and `fiddle' with RP0/RP1... >>Do intend TechTools to further develop also PSIM? >> PSIM was a `dead horse' long before TechTools took over... I use to use it when I was starting out with the 16C84 and 16C71. It would be nice to have an updated version but it's out of Parallax and TechTools's hands... - Tom