Searching \ for 'CVASM16' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/language/index.htm?key=asm
Search entire site for: 'CVASM16'.

Truncated match.
PICList Thread
'CVASM16'
1999\05\06@220208 by Bob Drzyzgula

flavicon
face
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_OUTbobTakeThisOuTspamdrzyzgula.org                until something bad happens
============================================================

1999\05\07@022200 by Dr. Imre Bartfai

flavicon
face
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}

1999\05\07@142523 by Andy Kunz

flavicon
face
>  * 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
==================================================================

1999\05\08@063117 by Tom Handley

picon face
  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}

1999\05\10@170637 by Jerry Merrill

flavicon
face
>
>   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

jerrymspamKILLspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\05\11@072930 by Tom Handley

picon face
  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}

1999\05\11@094100 by Jerry Merrill

flavicon
face
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_OUTspamTakeThisOuTtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\05\12@082659 by Tom Handley

picon face
  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}

1999\05\13@101009 by Jerry Merrill

flavicon
face
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@jerrymKILLspamspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\05\13@174809 by Tom Handley

picon face
  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

1999\05\14@092743 by Jerry Merrill

flavicon
face
At 02:47 PM 5/13/99 -0700, you wrote:
{Quote hidden}

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

KILLspamjerrymKILLspamspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\05\14@122448 by Andy Kunz

flavicon
face
>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
==================================================================

1999\05\14@123302 by ryan pogge

picon face
what is CVASM?

> >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
> ==================================================================
>

1999\05\14@134110 by Jerry Merrill

flavicon
face
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

RemoveMEjerrymTakeThisOuTspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\05\14@153235 by Bob Drzyzgula

flavicon
face
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}

--
============================================================
Bob Drzyzgula                             It's not a problem
spamBeGonebobspamBeGonespamdrzyzgula.org                until something bad happens
============================================================

1999\05\14@162806 by Jerry Merrill

flavicon
face
>
>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

TakeThisOuTjerrymEraseMEspamspam_OUTtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\05\15@015616 by Tom Handley

picon face
  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}

1999\05\15@073847 by Tom Handley

picon face
  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}

1999\05\15@093252 by Bob Drzyzgula

flavicon
face
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
EraseMEbobspamdrzyzgula.org                until something bad happens
============================================================

1999\05\17@021156 by Dr. Imre Bartfai

flavicon
face
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}

1999\05\17@052517 by Dr. Imre Bartfai

flavicon
face
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}

1999\05\17@070641 by Tom Handley

picon face
  Imre, I used STATUS,Z/SZ to point out one of the issues of converting
MPASM to CVASM. I would normally use JNZ but SZ/JMP generates the same
code.

  - Tom

At 11:26 AM 5/17/99 +0200, Dr. Imre Bartfai wrote:
{Quote hidden}

1999\05\17@094127 by Jerry Merrill

flavicon
face
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

RemoveMEjerrymTakeThisOuTspamspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

1999\05\17@143557 by Tom Handley

picon face
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

1999\05\17@183957 by paulb

flavicon
face
Tom Handley wrote:

>  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...

 I'm *absolutely fascinated* by this discussion.  To my mind an
assembler without macros and conditionals is *not usable* for serious
programming.  Agreed, you can use it with a generic preprocessor, but
the discussion then becomes how easy the pair can be used (within, say,
an IDE).

 Comparing programming in C to a non-macro assembler for example, as
appears to be a popular pastime, is hardly meaningful.  Of course, C is,
as has been often mentioned, itself BASICally a macro pre-processor. ;-)
--
 Cheers,
       Paul B.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...