----- Original Message ----- From: Dave Tweed To: Sent: Wednesday, May 18, 2005 8:46 PM Subject: [PIC] XCASM (was Re: CC5X errors - help) > Sergio Masci 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. 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 > > > > Why would I spend GBP100 or GBP1250 to switch to a tool I have no > > > control over? > > > > GPB 100 does not buy you a MPASM clone. It buys you a sophisticated > > professional assembler. If you can get by with MPASM or gpasm then you > > can use these free of charge. If you need something that improves your > > productivity (amongst other things greatly helps eliminate bank and page > > issuses which so many people find anonying) then XCASM is available. > > Regardless which route you take you are still paying unless your time is > > worth nothing that is. > > 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. 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? > > 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. 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. > > > > I'm not even sure that the "Enterprise Edition" supports the processors > > > I'm interested in. > > > > XCASM is a mata assembler, the enterprise edition gives full access to > > the configuration components. In other words you can define your own > > opcode syntax and the way it generates machine code. It comes with > > several processor definitions (e.g. Z80, 6502, 68HC11, PIC16 etc) which > > you can easily extend or change to suit your own requirements. You also > > get access to the intermediate high level opcodes of the "expression > > compiler" which you refer to above. This allows you to hack the > > expression compiler for other processors. XCASM enterprise edition is > > intended for people / companies who wish to develope their own CPU cores > > using FPGAs. > > 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. 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. > 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. 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 -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist