Sergio --

I didn't take offense at anything you said. Like I said before, I'm just
trying to help you sell your products.

This whole discussion started out when a user of Olin's *free* macro library
mentioned a minor issue, and I offered a *free* simple Perl script that
helps to address that issue. You chimed in with a reference to your XCASM,
which not only costs money, but appears to work in a way that is
fundamentally incompatible with the entire rest of the MPASM/gpasm world.

Being different is fine, especially if it allows you to accomplish things
that can't be done in the standard way, but you create an uphill battle
for yourself in terms of marketing your tools -- you have to provide the
documentation that allows a user to decide to "jump ship" and switch their
code base over to your way of doing things. This is not an easy decision
for anyone who already has a lot of development history with these
processors.

Although you've offered a lot of additional information in this discussion,
you still have failed to address some fairly basic questions:

> > I can't tell what the output format of your assembler is.
> > 
> > So, how do I ... get my code into the PIC?
> >
> > In which case, I don't get to take advantage of existing libraries of
> > macros and/or executable code.

To this, I would add: How do I debug my XCASM code on the actual hardware?

You address the library question by speculating about the possible nature
of my macro and code libraries. But you can't possibly anticipate all of my
needs with features built into the tool.

To take the specific example of floating-point arithmetic. I may have a
thoroughly debugged floating-point library that uses an internal
representation that's completely different from the one used in XCASM (on
which there's no documentation[1]). It would be a major overhaul of all of
my code that is based on that library to switch over to XCASM.

> Correct, however MPASM doesn't come with support for any other non-PIC
> MCU.

We weren't talking about non-PIC MCUs here. And even if we were, my Perl
scripts work with any MCU/MPU/DSP that has an assembler.

> Ok, maybe you don't want to play with FPGAs but if you did how would
> MPLAB help you?

If I had a CPU core for an FPGA that adhered to the PIC ISA, MPLAB would
work just fine as an assembler/linker/librarian. It just wouldn't support
hardware debugging. But I have FPGA tools for that.

> A description of the meta language and how it is used to generate code
> is IP. It cost a lot to develope and get right. Simply giving this
> information away so that the software can be replicated would put me
> at a disadvantage.

Now that's a strange attitude. There must be some level of documentation
that you provide to users of the Enterprise Edition so that they can
develop an assembler for a custom processor. Why does it completely destroy
your business model to provide that documentation up front, to aid in the
decision to purchase your product in the first place?

-- Dave Tweed

[1] In fact, there's no mention at all on the website that XCASM has
    built-in floating-point support. This is the first I've heard of it!
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist