Searching \ for '[PIC] XCASM (was Re: CC5X errors - help)' 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/microchip/languages.htm?key=asm
Search entire site for: 'XCASM (was Re: CC5X errors - help)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] XCASM (was Re: CC5X errors - help)'
2005\05\18@154630 by Dave Tweed

face
flavicon
face
Sergio Masci <spam_OUTsmplxTakeThisOuTspamxcprod.com> wrote:
> Dave Tweed wrote:
> > I can't tell what the output format of your assembler is. Is it
> > compatible with the MPLAB linker?
>
> No. XCASM produces far more information about an executable than the
> MPLAB linker can deal with e.g. XCASM handles floating point directly,
> produces RAM bank and code page diagnostic information which the XCSIM
> simiulator can use to track incorrect bank and page setting during
> program simulation.

So, how do I link my modules together and get my code into the PIC?
That's never addressed in the online documentation.

> > Can it accept MPASM/gpasm source code?
>
> assembler source yes, assembler directives no.

In which case, I don't get to take advantage of existing libraries of
macros and/or executable code.

{Quote hidden}

Except that MPASM supports *all* of the PICs, not just a selected set.
>From what you say below, I infer that although the Enterprise Edition of
XCASM gives me access to the meta tools, it doesn't come with support
for any additional Microchip processors over the "PIC locked" version.

My Perl scripts are not processor specific, so they do not limit me in any
way. They merely extend the syntax of the underlying assembler in carefully
controlled ways. Unaugmented source code will pass through them unmodified.

> I assume that by "control over" you mean "one that you have the source
> code for and can fix yourself". Yes I know that many people think like
> this but even so these people are in the minority. Most people do not
> want to fix a program they find bugs in, they either want it fixed for
> them or they look for a workaround.

But your website never makes it clear how much support I can expect. In
many ways, it gives the appearance of a one-man shop that may not be any
more responsive to issues than I am when maintaining my own code.

{Quote hidden}

I'm not interested in a tool that I have to "hack" (your term) to support
standard products. I'd rather invest that time in my own code base.

Furthermore, there's zero documentation on your website about the
metalanguage used in the Enterprise Edition. It must be quite expressive
if you can use it to describe the banking and paging requirements of a
PIC and then do the global flow analysis and optimization of the inserted
instructions. I would think this would be a major selling point.

I'm trying to help you out here. In your last several messages, you've
revealed quite a bit of interesting information about your products that
isn't readily available (if at all) on your website. I'm just trying to
point out that you would capture a lot more interest in your products if
you'd place this kind of information on your website in a well-organized
manner. While you're at it, fix all of the spelling and grammatical
errors as well. People will be a lot less hesitant about spending
professional-level prices for tools if they look like they come from a
professional-level outfit.

-- Dave Tweed

2005\05\19@020222 by cdb

flavicon
face

:: But your website never makes it clear how much support I can
:: expect. In
::
:: many ways

I just have to say, that Sergio normally responds to any problems or
queries I have in about 24hours (He's UK, I'm Oz). Also the forum
normally gets replies pretty quickly as does the XCSB support list.

Colin


--
cdb, .....colinKILLspamspam@spam@btech-online.co.uk on Thursday,19 May,2005

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359

Light travels faster than sound. That's why some people appear bright
until they speak!



2005\05\20@072610 by Sergio Masci

flavicon
face

----- Original Message -----
From: Dave Tweed <picspamKILLspamdtweed.com>
To: <.....piclistKILLspamspam.....mit.edu>
Sent: Wednesday, May 18, 2005 8:46 PM
Subject: [PIC] XCASM (was Re: CC5X errors - help)


{Quote hidden}

To date there has been no need for a link editor. XCASM can deal with code and
section allocation and fixing directly. The argument concerning speed of code
generation (linking code from sperately assembled source files) is dead because
of the raw processing power of a modern day PC.

XCASM will allow you to conditionaly place code and data sections depending on
the values computed during the assembly stage. In effect the conditional
assembly process seamlessly extends to the link process. You don't need to
tinker with external linker scripts, all the control is placed directly in the
assembler source. This is not implemented as some seperate layer within the
assembler but directly integrated into the whole of the assembly process.
Expressions (including conditional expressions) use the actual fixed address of
an object so moveing things around between assembly passes because they don't
fit a given memory area is easy. You don't have to write relocateable code that
needs to compensate for not knowing some information that is only available
after the code has been linked. You can write complicated macros to do all the
hard work of seperating data structures into different data spaces and then pack
them into a continuous region without resorting to a linker. You can generate
optimised executables where code can be included or omited depending of the
final address of an object without jumping through hoops scraping information
from linker listings and then folding it back into the assembler source (which
tends to be error prone anyway). The whole code generation and development
process is greatly simplified and the benefits on a medium to large project are
enourmous. The generated listing contains fully relocated addresses and there is
no need to continually refer to the linker listing when reading the assembler
listing.

>
> > > Can it accept MPASM/gpasm source code?
> >
> > assembler source yes, assembler directives no.
>
> In which case, I don't get to take advantage of existing libraries of
> macros and/or executable code.

Taking advantage really depends on there being an advantage. If you have dozens
of macros dedicated to floating point manipulation which become redundent
because XCASM directly supports floating point then I would argue that you have
a net gain not a lose.

Similarly for macros that deal with extended precission arithmetic such as add
and subtract of 16 and 32 values. XCASM has a built-in expression code generator
so instead of writing

       add16    X, Y

you would write:

       .let X = X + Y

Also because the built-in expression code generator is fully aware of object
properties such as width you don't need to worry about selecting the right macro
for an object. It's kind of like a context sensitive macro calling mechanisum

e.g.
if X and Y are defined as 16 bit variables

i.e.
       X    .dsw    1
       Y    .dsw    1

then

       .let X = X + Y

is equivalent to

       add16    X, Y

whereas is X and Y are defined as 32 bit variables

i.e.
       X    .dsl    1
       Y    .dsl    1

then the same

       .let X = X + Y

is equivalent to

       add32    X, Y

{Quote hidden}

Correct, however MPASM doesn't come with support for any other non-PIC MCU. The
whole point about XCASM enterprise edition is not that it comes with support for
the 17 series but that you can quickly and easily configure a high quality
professional tool to do what you need it to. Say you have some PIC code for a
16F877 and you need it to run at 100 MIPS and extend the code to 16k
instructions. What do you do, throw away the 16F877 and maybe look at something
like an LPC2100 or would you prefer to take a PIC core extend it and put it into
an FPGA. Ok, maybe you don't want to play with FPGAs but if you did how would
MPLAB help you?

{Quote hidden}

Unlike MOST other software vendors who simply say you will be entitled to XX
months of support or updates I actually specify the number of issues (support
requests) you are paying for. Any paid for requests get added to the "paid for
support queue". Once you have exceaded this number your requests get added to
the "unpaid for support queue". If you require a higher level of support you can
pay for a support contract.

> In
> many ways, it gives the appearance of a one-man shop that may not be any
> more responsive to issues than I am when maintaining my own code.

Many people see this web site differently (to you and each other). Some people
are shocked when they find that it is a one man shop. Some are impressed, some
express concerns. I have sold software to some very large companies without any
problems. Some people that pay a lot expect that there will be bugs and are
happy with a quick work around, others that pay pennies expect immediate devoted
support.

The only thing that is constant is that everyone has a different view of what
they want and expect regarding both support AND the web site.

{Quote hidden}

Again, different people have different requirement and expectations. Some
companies want their employees to work on their product and are happy to buy in
tools sometimes paying for them to be tailored. But ultimately the point must
be: if you can buy a product that saves you half the work on half of your
development then it is better than not buying the product because it does not
save you half the work on all of your development.

If you would rather build up your own code base then more power to you. I have
no problem helping you or people like you where I can (I provide the XCSB lite
compiler free for personal non-commercial use, I provide free help for people
who need it regarding this compiler and other completely unrelated maters).

I remember when a hacker was a revered programmer, an intelligent motivated
individual, someone that cut his way through obsticals, read between the lines
and made his systems sing and dance. When I said you could "hack" it, I was
talking as one such indivdual to another. It did not occure to me that you would
take offense.

As a mater of interest how well has the PIC port of the SDCC compiler come along
in the last 2 years? Apart from Scott's work on this I don't see anybody else
contributing to it. Whereas version 2 of the XCSB compiler has come a long way
since it was started at the end of last year. Does open source really mean
better development tools for the PIC?

>
> Furthermore, there's zero documentation on your website about the
> metalanguage used in the Enterprise Edition.

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.

{Quote hidden}

I appreciate your comments and I understand my web site needs a major overhaul.
It has been on my list of things to do for a long time now.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use






2005\05\20@084443 by Dave Tweed

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

2005\05\20@120459 by Scott Dattalo

face
flavicon
face
Sergio Masci wrote:

<snip>

> As a mater of interest how well has the PIC port of the SDCC compiler come along
> in the last 2 years? Apart from Scott's work on this I don't see anybody else
> contributing to it. Whereas version 2 of the XCSB compiler has come a long way
> since it was started at the end of last year. Does open source really mean
> better development tools for the PIC?

Sergio,

I agree with the premise behind your statement but would like to correct
 the facts. The fact is that I've done hardly anything with SDCC for
the last two years, but there have been at least two other very active
contributors to the SDCC port (and in particular to the 16bit processor
support). Now this fact ties into your premise; my motivation for
contributing to an open source project has less to do with satisfying
the needs of others and more about satisfying my own. Whereas your work
on XCSB and XCASM must address the needs of others else you'll not be
able to eat next week. And if we both do our job equally well, in the
end you'll have a tool others can use whereas I'll have a tool that I
can use. To the degree that my uses coincide with those of others, our
tools will satisfy similar goals.

Scott

2005\05\24@093054 by Sergio Masci

flavicon
face

----- Original Message -----
From: Dave Tweed <picspamspam_OUTdtweed.com>
To: <@spam@piclistKILLspamspammit.edu>
Sent: Friday, May 20, 2005 1:44 PM
Subject: Re: [PIC] XCASM (was Re: CC5X errors - help)


{Quote hidden}

The assembler generates a binary executable for the target processor. The binary
can be output in one of several formats which are compatible with most device
programmers, in circuit programmers and in circuit emulators (ICE). Intel HEX is
one such format.

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

I agree I cannot anticipate ALL your needs but as an experienced assembler
programmer of almost 30 years standing, someone who has experience of many CPUs,
I belive I am in a position to anticipate a great many needs.

The point I was trying to make was not that you should throw away all your code
and replace it with XCASM specific stuff but that there are great advantages in
using XCASM.

Ok, so what you're telling me is that I should really look to having a
simplified migration path between MPASM and XCASM. Your point is well taken and
I shall look carefully into this.

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

Agreed. However I should point out that XCASM uses the IEEE 754 single precision
floating point standard for the PIC and being a meta assembler there are
previsions for using different floating point formats (it would be pretty
useless otherwise).

So again a simplified migration path would resolve this problem by allowing you
to use your libraries with very little change.

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

But you brought up the enterprise edition. I was pointing out the difference
between this and the pro edition. The reason why the enterprise edition is so
much more expensive than the pro edition.

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

I obviously didn't make myself very clear on this. If you start off with a well
defined processor core and target software that runs on that core then move it
to an FPGA, there will be tweeks that you can do to the instruction set that
will give you great performace boosts. For example you might decide to add some
extra bits to each instruction and increase the number of directly accessable
RAM locations, or add a second W register, or implement some special high level
instructions. MPLAB would not be able to deal with this at all. Whereas XCASM
could accomodate this in minutes.

{Quote hidden}

No not really. By showing people the end result you put them on the RIGHT path
to cloning your software right from the start. If they need to develop it
themselves, they will need to do the research themselves and bare the cost
themselves. This would completely put off a small company or a talented student
looking for something to do. If they don't have your costs then they can
immediately undersell you so you are at a disadvantage. It's a bit like putting
out a patent on some hardware, if you show people how to do a job then you have
to fight the pirates. If you don't show them then it's very much harder for the
pirates to move in.

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

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use






2005\05\24@095205 by Sergio Masci

flavicon
face

----- Original Message -----
From: Scott Dattalo <KILLspamscottKILLspamspamdattalo.com>
To: Microcontroller discussion list - Public. <RemoveMEpiclistTakeThisOuTspammit.edu>
Sent: Friday, May 20, 2005 5:04 PM
Subject: Re: [PIC] XCASM (was Re: CC5X errors - help)


> Sergio Masci wrote:
>
> <snip>
>
> > As a mater of interest how well has the PIC port of the SDCC compiler come
along
> > in the last 2 years? Apart from Scott's work on this I don't see anybody
else
> > contributing to it. Whereas version 2 of the XCSB compiler has come a long
way
{Quote hidden}

Hi Scott,

I think I should make it clear that at no point was I criticising you, your work
or your decision to publish your work as opensource. I am VERY sorry if I have
given you this impression as I actually think highly of you.

What I was trying to highlight is that although many people complain about
non-opensource software (that it cannot be maintained by the user) that there is
a great deal of opensource software which is not maintained by its users. I was
trying to say that if it were not for Scott (and maybe one or two others which I
admit I was not aware of) the PIC port of SDCC would have died. Users are not
queing up to fix bugs in it. The argument that software must be maintainable by
its user is completely contradicted by the unwillingness of MOST users to fix
buggy software even when given the opportunity.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\05\24@101128 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: spamBeGonepiclist-bouncesspamBeGonespammit.edu [TakeThisOuTpiclist-bouncesEraseMEspamspam_OUTmit.edu]
>Sent: 24 May 2005 14:58
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] XCASM (was Re: CC5X errors - help)
>
The argument that software must be maintainable by its
>user is completely contradicted by the unwillingness of MOST
>users to fix buggy software even when given the opportunity.

I would say "inability" rather than unwillingness.  A C compiler is a
complex program by anyones standards, and most of the people wishing to
use a free C compiler are going to be hobbiests who are also likely to
be learning the language as they go (if my experiences from the Piclist
and the HiTech forums are anything to go by).

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\05\24@104413 by Alan B. Pearce

face picon face
>>The argument that software must be maintainable by its
>>user is completely contradicted by the unwillingness of MOST
>>users to fix buggy software even when given the opportunity.
>
>I would say "inability" rather than unwillingness.  A C compiler
>is a complex program by anyones standards, and most of the people
>wishing to use a free C compiler are going to be hobbiests who are
>also likely to be learning the language as they go (if my
>experiences from the Piclist and the HiTech forums are anything
>to go by).

<VBG> I think you have hit the nail on the head as far as compilers go.

There are enough of us here making use of the arithmetic abilities of
various people to get items such as multi-byte arithmetic squeezed into
minimal routines, to illustrate the problem most of us have with basic
operations without dealing with compiler internals.

2005\05\24@112728 by Dave Tweed

face
flavicon
face
Sergio --

> The assembler generates a binary executable for the target processor. The
> binary can be output in one of several formats which are compatible with
> most device programmers, in circuit programmers and in circuit emulators
> (ICE). Intel HEX is one such format.

Ugh. OK, so I get zero source-level debug support, even though your
assembler is inserting instructions and compiling expressions for me.

> ... I should point out that XCASM uses the IEEE 754 single precision
> floating point standard for the PIC ...

You missed my footnote -- there is absolutely no mention of floating-point
support at all in your XCASM documentation, so there is no way I could have
known this.

IEEE 754 is not a particularly good choice for an embedded 8-bit processor.
All of the exceptions that need to be handled tend to cut seriously into
the performance. Unless, of course, you're only implementing a subset of
the standard -- but then you need to carefully document the subset.

> But you brought up the enterprise edition.

Only because I couldn't tell from the documentation whether it supported
a larger set of PICs than the PIC-locked version. The answer is yes, it
*can*, but I have to "hack" that support into it myself, using a
metalanguage whose documentation I can only guess at.

> I obviously didn't make myself very clear on this. If you start off with
> a well defined processor core and target software that runs on that core
> then move it to an FPGA, there will be tweeks that you can do to the
> instruction set that will give you great performace boosts. For example
> you might decide to add some extra bits to each instruction and increase
> the number of directly accessable RAM locations, or add a second W
> register, or implement some special high level instructions. MPLAB would
> not be able to deal with this at all. Whereas XCASM could accomodate this
> in minutes.

As a tool vendor, you have a highly distorted view of the world.

Isn't it obvious that while I could indeed extend a processor architecture
in the ways that you suggest, it would have absolutely no effect on the
performance of my application code UNLESS I completely rewrite that code
to take advantage of the extensions? A few minutes of work in XCASM is only
the beginning! Also, I would have to completely abandon whatever tool chain
that I used to create that code in the first place.

Granted, MPLAB can't be used if you change the width of an instruction, but
all of the other cases can be handled by an appropriate set of macros
and/or access functions.

And if I was really interested in performance on an FPGA, I'd start with an
architecture that's already fairly optimal for the FPGA in question (e.g.,
Nios on Altera, Microblaze on Xilinx) and start extending from there. These
architectures come with well-developed toolchains that are intended to
handle extensions to the ISA. Or I'd start translating critical sections of
application code into HDL for direct implementation on the hardware.

-- Dave Tweed

2005\05\24@112832 by Sergio Masci

flavicon
face

----- Original Message -----
From: Alan B. Pearce <RemoveMEA.B.PearcespamTakeThisOuTrl.ac.uk>
To: Microcontroller discussion list - Public. <piclistEraseMEspam.....mit.edu>
Sent: Tuesday, May 24, 2005 3:44 PM
Subject: Re: [PIC] XCASM (was Re: CC5X errors - help)


{Quote hidden}

whether it is unwillingness OR inability the fact is that a great many people
who bellyache about access to the compiler source would not actually go near it
with a barge pole even if you paid them.

It is irritating to hear people complaining that your software is not opensource
and using this as an excuse not to buy it. Given the amount of advise I see
floating about regarding circumventing the HiTech PIC C compiler restrictions I
wonder where this would stop if the source code were available.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use





2005\05\25@091700 by Sergio Masci

flavicon
face

----- Original Message -----
From: Dave Tweed <EraseMEpicspamdtweed.com>
To: <RemoveMEpiclistEraseMEspamEraseMEmit.edu>
Sent: Tuesday, May 24, 2005 4:27 PM
Subject: Re: [PIC] XCASM (was Re: CC5X errors - help)


{Quote hidden}

No it is not completely obvious to me.

Something that is obvious to me (as someone who has written a hell of a lot of
software, both high level and low level and someone who has written compilers
and CASE tools), is that 90% of embedded applications that need a speed increase
can easily gain this speed increase using a small hardware boost and trivial
software modifications. When apps running on a PC need to go faster, users tend
to add faster CPUs or RAM or higher performance chipsets (via a new mother
board). When this is still insufficent, they add faster graphics cards or hard
disc controllers or network interface cards. Ok, you need different device
drivers for these but the underlying app stays the same.

When Intel wanted to boost its Pentium processors, it did not make the machine
code incompatible with previous processors, it extended the instruction set and
added extra hardware to the CPU. Most apps saw an immediate improvement and in
some cases small sections of the apps were modified to take advantage of the new
CPU features.

>A few minutes of work in XCASM is only
> the beginning!

No I disagree. Say for the sake of argument that you increased the instruction
word width from 14 bits to 16 bits and you used the extra bits to extend the
register address field for instructions that access registers and the
destination field of instructions that change the PC. You would see an immediate
improvement in processor performance by simply changing your bank and page
select macros to do nothing. Furthermore because the address is now completely
contained within the instruction it becomes much easier to add features to the
CPU to speed it up.

If you added a second W register you could improve the performance of small time
critical sections of code without changing the majority of your code. If you
added specialised instructions (maybe shift W by N places) again you could
improve small sections of code. The point is that MOST of your code would not
change.

And this holds true for other CPUs not just the PIC. In fact look at some of the
6502 varients which are capable of running legacy 6502 code with only the
tinyest of changes in the start up / config code, yet they have additional
hardware and registers which can be used to boost performance of very small time
critical sections of code.

{Quote hidden}

But your whole argument was that you have established well debugged libraries of
code and macros. You would need to ditch these to move to another CPU. Ok so the
migration path between the XCASM and MPASM assemblers could be a lot better but
the fundamental premis that you continue to use your existing app (with MINOR
tweeks) on a faster CPU is still valid.

Also "translating time critical sections of the application into HDL for direct
implementaion on the hardware" integrates better (read faster and more compact)
if the extensions can be triggered directly via excuting instructions instead of
through ports. Again this comes down to extending the machine code instructions.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use






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