Sign in
Search piclist
Subscribe to piclist
piclist by Keywords
12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx
Ads
Discussion Groups
See Also
Discussion Groups | Piclist | New ASM vs C
A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.
Re: Re: New ASM vs C - Paul James E. - Nov 5 5:36:00 2004
|
All, Like I've said several times before, IMHO, for PIC's, ASM is the way to go. I've tried 'C', and as has been explained here (and elsewhere), it just doesn't give you (me) the control you (I) like. I've also tried 'BASIC' and have abandoned it for the most part for the same reasons. I even tried 'JAL', but left it without really giving it a thorough workout because I didn't want to climb the learning curve with it. I am proficient enough in ASM that I can write an app in ASM in about the same amount of time I'd use to write in a HLL. I'm not an expert by any stretch of the term, but I can hold my own. Bottom line..., I'll probably just stay with ASM, and not worry about HLL's any more unless the customer specifically wants the code in a given HLL. Later all. Regards, Jim > >> >> It is. Been there, done that. But when you want to abstract the > next >> level of HLL (procedure/function, local variables, optimization of >> constant expressons, ...) things get very ugly. Been there, tried > that, >> ended up writing a compiler instead. > > Absolutely true! But, it isn't the language so much as the > hardware. No data stack, no indirect or indexed addressing (and I > don't count FSR and INDF as indexed - what a kludge!), no registers > (using RAM through W and calling it a register hardly qualifies) and > limited memory (16F series) makes things like parameters, local > variables and functions very difficult to write. C doesn't improve > the hardware, it just hides the nasty details. The emitted code is > just as ugly, if not more so, than if it was written in ASM. > > And, when it comes time to port? Well, there's ANSI C, and then > there's C. Some implementations are better than others. CC5X (free > version), for example, can't handle complex (difficult, not > imaginary) expressions and refuses to accept function pointers in > arrays (among other problems). So, instead of using function > pointers in my scheduler, I had to use a case statement. > > I wasted 4 hours with PIC C (demo version) the other day trying to > offset the code origin and reserve the first 3 addresses for my boot > loader. Complete waste of time - as near as I can tell it can't be > done since they use a long jump as the first instruction seqence. It > is possible in PIC C Lite because I have done it and both > versions purport to use the same 'powerup.as' code - I gave up > before getting it to work. Something as simple as setting the code > origin and the compiler gets in the way. > > And so it goes, every implementation has warts. The only universal > constant is the assembler provided by the manufacturer - the common > denominator. Everything else is non-portable or limited to a >specific series of devices. What if you want to move to the latest >whiz bang micro and your compiler writer hasn't gotten around to > it? It's pretty certain that MPLAB will support the device as soon as > it's available. > > I do like C and I use C from time to time. When I was writing a > cooperative multitasking project, C was the way to go. A couple of > days ago I was writing a simple program to get data from the serial > port and feed it out using the SPI protocol. Given the tools at > hand, ASM was the easiest way to get it done. > > It just doesn't matter - whatever gets the project complete. >> >> > Macro invocations like: >> > >> > LED 7,ON >> > SPI_Clk HI >> > SPI_CS_n LO >> >> In C they could look like >> >> LED( 7, ON ); >> SPI_Clk( HI ); >> SOI_CS_n( LO ); >> >> soo that's no argument for or against HLL. >> > > But what does the code look like? In the ASM case it might be >simple: load the mirrored copy of the port, mask in the bit, save the >mirrored copy and write to the port. Four instructions, > assembled in line. > > In the C case (no fair using the macro preprocessor and inline > assembly), the code to invoke a function LED with two parameters, > perform some operation and return could be quite large and not > particularly pretty. And, of course, the function itself still has to > be written. > >> > And Dan's point needs to be considered. If timing requirements > are >> > important, ASM is predictable, nothing is hidden away in a > library, >> > every instruction cycle is on display. >> >> Again, you don't *have* to hide stuff in a HLL library, if every > cycle >> matters you simply don't. > > If every cycle matters, C is not the way to go. I was just messing > around with a PIC Pong game where every instruction counts toward > timing the video. Definitely not a place for a high level language! > > We can debate this forever - you're still going to win. My first > computer language was Fortran; ASM didn't come until much later and > then it was the only thing available. If Fortran hadn't been > available I doubt I would have ever gotten started with programming! > > I don't really have a preference for a language for the PIC. The only > language I really enjoy is Pascal and just as I was about to finally > use it the demo period expired! It looks good, however : > http://www.picant.com/p2c/p.html But, again, it would be non- > portable and device limited. > >> >> Wouter van Ooijen >> >> -- ------------------------------------------- >> Van Ooijen Technische Informatica: www.voti.nl >> consultancy, development, PICmicro products >> docent Hogeschool van Utrecht: www.voti.nl/hvu > > > to unsubscribe, go to http://www.yahoogroups.com and follow the > instructions Yahoo! Groups Links |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
New ASM vs C - wantoniet - Nov 5 5:38:00 2004
|
Hi folks! It is not a new issue, but let me focus the discussion once again on battle "ASM vs C". I need advices to have an more solid opinion on it. Our company work with a third part that programm for us many embedded products for a long time ago. We purchased CCS compiler and use it sparced times and think its a better way to programm bulk software. Although our trend is C, third part do not commited us in use this language. Why? They tell: - If you programm well with ASM YOU DO NOT NEED C! - The portability of C is not true! - C is for ignorant programmers! - With C you do not have total control of the machine! Please repplies are welcome. I do not have much C experience to disagree our third part. What can we say about ASM vs C? Thanks... Wilson |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: New ASM vs C - Igor Janjatovic - Nov 5 7:56:00 2004
|
> - If you programm well with ASM YOU DO NOT NEED C! > - The portability of C is not true! > - C is for ignorant programmers! > - With C you do not have total control of the machine! No comment. Regards, Igor |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
RE: New ASM vs C - Wouter van Ooijen - Nov 5 10:58:00 2004
|
> - If you programm well with ASM YOU DO NOT NEED C! If - they can program as fast and as good (bug rate wise) in asm as a good C programmer can do in C, - and you don't need anyone else (but them) to modify the code lateron, then they are right. I personaly doubt this is the case. (Note: on PICs I use assembler, C, Jal, whatever I find the best tool for the job at hand. Choosing assembler is rare). > - The portability of C is not true! C is not absolutely porteable, especially not on microcontrollers, but still a lot easier to port than let's say PIC-14 assembler to 8051. > - C is for ignorant programmers! If they consider this a serious argument you can decide for yourself whether you should take any argument (from them) serious. > - With C you do not have total control of the machine! You can if you want to (use a compiler that can embed assembler), but you don't *need* to. > What can we say about ASM vs C? Both have thier place. High volume (large production series) and thight timing control are arguments for asembler. Low volume, complex application, and short development time are arguments for HLL (not just C). Having a programmer (human) available that is experienced in asm (or C) arguments for that particular language. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: New ASM vs C - Michael Puchol - Nov 5 11:19:00 2004
|
If you shift individually the 1s and 0s directly, YOU DON'T NEED ASM! Everyone is fluent in one or more languages. There are no "better" or "worse" languages as such, there are only languages more targeted to particular users or environments. If you need full control of your code, low-level tweaking, etc. then go for ASM. If you are like me, who develops projects that need to be done quickly and without particular care if the code will be a few bytes larger or smaller, then you could use C or a BASIC-like language. As I mentioned, I use Proton+, and I can develop stuff in hours that would take me days to do in C, never mind in ASM. Also, as mentioned, code in structured languages is clearer and easier to port & understand by others than the original programmer. I can read C pretty well, and could translate a C program to BASIC with relative ease, I wouldn't try with ASM. I will never look down on someone just because he uses a higher-level language than I, he has simply chosen the best tools that suit him. Best regards, Mike ----- Original Message ----- From: "Igor Janjatovic" <> To: <> Sent: Friday, November 05, 2004 1:56 PM Subject: Re: [piclist] New ASM vs C > >> - If you programm well with ASM YOU DO NOT NEED C! >> - The portability of C is not true! >> - C is for ignorant programmers! >> - With C you do not have total control of the machine! > > No comment. > > Regards, > Igor > > > to unsubscribe, go to http://www.yahoogroups.com and follow the > instructions > Yahoo! Groups Links |
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: New ASM vs C - dan michaels - Nov 5 11:23:00 2004
|
--- In , "wantoniet" <wantoniet@y...> wrote: > > Hi folks! It is not a new issue, but let me focus the discussion once > again on battle "ASM vs C". I need advices to have an more solid > opinion on it. Our company work with a third part that programm for > us many embedded products for a long time ago. We purchased CCS > compiler and use it sparced times and think its a better way to > programm bulk software. > Although our trend is C, third part do not commited us in use this > language. Why? They tell: > - If you programm well with ASM YOU DO NOT NEED C! > - The portability of C is not true! > - C is for ignorant programmers! > - With C you do not have total control of the machine! > > Please repplies are welcome. I do not have much C experience to > disagree our third part. > > What can we say about ASM vs C? > > Thanks... > > Wilson The "usual suspects"! Regards the following .... > - With C you do not have total control of the machine! .... depending on your application and the C compiler being used, you may or may not have adequate control of the machine. However, if your app has real-time + time-critical aspects, then when using C you may not know the exact times it takes various built-in C routines to run or they may take longer than you wish. Someone on another forum was using multiple interrupts using built-in C interrupt routines, and the overhead was killing him. You can get around some of this by being able to link C + assembler, but it probably depends a lot on the specific application. A lot of what I do with PICs has very critical timing aspects, and in this case assembler is probably best. If the timing aspects aren't so critical, then C is probably ok in most cases. - dan michaels www.oricomtech.com ====================== |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: New ASM vs C - rtstofer - Nov 5 12:22:00 2004
|
In some ways it comes down to productivity. It has long been rumored that IBM studied the issue extensively and came up with a metric that a programmer could write about 100 deliverable lines of code per day. The thought was that, the higher the level of the language, the more was actually accomplished with the 100 lines of code. This argues in favor of a high level language. It is certainly true that modeling stellar dynamics in assembly language is a misuse of ASM - the application is so complex that a higher level language or even a specific purpose language would be more appropriate. But when it comes to twiddling bits perhaps the abstraction of the higher level language makes the process more obscure and more difficult. Maybe not. The real trick is a good library, whether at the ASM level or at a higher level. For the ASM programmer it might include a collection of macros. It is possible to create macros for all of the program flow statements (IF-THEN-ELSE, WHILE <expr> WEND, REPEAT UNTIL) to elevate that level of code while still dealing directly with the bits. More important is the ability to create application specific macros that make the application even more apparent. Macro invocations like: LED 7,ON SPI_Clk HI SPI_CS_n LO make it very easy to document exactly what is going on in terms of application specific concepts. I am not sure that porting a PIC project to an 8051 is relevant. The hardware is so different that probably 90% of the code would be scrap. In fact, to the extent that programs interact with hardware, at least in the context of microcontrollers, all of the code would be scrap. Overall program flow would be similar (or even identical) but nothing below the top level would be useful. I wonder if using application specific macros would give the edge to ASM in this type of port? There is also the issue of 'patterns'. In ASM, there are just so many ways a particular piece of code might be written and programmers, being a lazy bunch, get into the habit of using a pattern. Other programmers, being just as capable, see the pattern for what it is: a loop, a conditional test, etc. You can just look at a sequence of instructions and gather what is going on. Now, I'll admit it is more difficult than the same test in C but it is still a pattern. One of the 'features' of the PIC is that there are very few ways any particular operation might be coded. The instruction set is so small that there aren't all that many choices! But to see really obscure assembly code, look at the output of various compilers. You need to be a great ASM programmer to debug C at the assembly level. For your purposes the answer doesn't lie in C vs ASM as a language. What matters is results. Are your programmers getting the job done on time? How does their cost compare with quotes from other vendors that might be using some other language? It just doesn't matter what language is being used, what matters is the result. Does the product work? Can it be marketed at a profit? You probably won't port the application; there will be so many 'enhancements' in the next version that a complete rewrite will be required anyway. And purchasing will want to buy cheaper devices, marketing will want more features, accounting will want profits; who cares how it is coded? And Dan's point needs to be considered. If timing requirements are important, ASM is predictable, nothing is hidden away in a library, every instruction cycle is on display. |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
RE: Re: New ASM vs C - Wouter van Ooijen - Nov 5 14:13:00 2004
|
> But when it comes to twiddling bits perhaps the abstraction of the > higher level language makes the process more obscure and more > difficult. Maybe not. Certianly not unless you want it. Every serious uC HLL allows you to insert assembly in-line in the HLL program, so you can have all the benefits of asm for the (in most cases very small) pieces where it matters. > It is possible to create macros for all of the program > flow statements (IF-THEN-ELSE, WHILE <expr> WEND, REPEAT UNTIL) It is. Been there, done that. But when you want to abstract the next level of HLL (procedure/function, local variables, optimization of constant expressons, ...) things get very ugly. Been there, tried that, ended up writing a compiler instead. > Macro invocations like: > > LED 7,ON > SPI_Clk HI > SPI_CS_n LO In C they could look like LED( 7, ON ); SPI_Clk( HI ); SOI_CS_n( LO ); soo that's no argument for or against HLL. > And Dan's point needs to be considered. If timing requirements are > important, ASM is predictable, nothing is hidden away in a library, > every instruction cycle is on display. Again, you don't *have* to hide stuff in a HLL library, if every cycle matters you simply don't. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: New ASM vs C - rtstofer - Nov 5 17:07:00 2004
|
> > It is. Been there, done that. But when you want to abstract the next > level of HLL (procedure/function, local variables, optimization of > constant expressons, ...) things get very ugly. Been there, tried that, > ended up writing a compiler instead. Absolutely true! But, it isn't the language so much as the hardware. No data stack, no indirect or indexed addressing (and I don't count FSR and INDF as indexed - what a kludge!), no registers (using RAM through W and calling it a register hardly qualifies) and limited memory (16F series) makes things like parameters, local variables and functions very difficult to write. C doesn't improve the hardware, it just hides the nasty details. The emitted code is just as ugly, if not more so, than if it was written in ASM. And, when it comes time to port? Well, there's ANSI C, and then there's C. Some implementations are better than others. CC5X (free version), for example, can't handle complex (difficult, not imaginary) expressions and refuses to accept function pointers in arrays (among other problems). So, instead of using function pointers in my scheduler, I had to use a case statement. I wasted 4 hours with PIC C (demo version) the other day trying to offset the code origin and reserve the first 3 addresses for my boot loader. Complete waste of time - as near as I can tell it can't be done since they use a long jump as the first instruction seqence. It is possible in PIC C Lite because I have done it and both versions purport to use the same 'powerup.as' code - I gave up before getting it to work. Something as simple as setting the code origin and the compiler gets in the way. And so it goes, every implementation has warts. The only universal constant is the assembler provided by the manufacturer - the common denominator. Everything else is non-portable or limited to a specific series of devices. What if you want to move to the latest whiz bang micro and your compiler writer hasn't gotten around to it? It's pretty certain that MPLAB will support the device as soon as it's available. I do like C and I use C from time to time. When I was writing a cooperative multitasking project, C was the way to go. A couple of days ago I was writing a simple program to get data from the serial port and feed it out using the SPI protocol. Given the tools at hand, ASM was the easiest way to get it done. It just doesn't matter - whatever gets the project complete. > > > Macro invocations like: > > > > LED 7,ON > > SPI_Clk HI > > SPI_CS_n LO > > In C they could look like > > LED( 7, ON ); > SPI_Clk( HI ); > SOI_CS_n( LO ); > > soo that's no argument for or against HLL. But what does the code look like? In the ASM case it might be simple: load the mirrored copy of the port, mask in the bit, save the mirrored copy and write to the port. Four instructions, assembled in line. In the C case (no fair using the macro preprocessor and inline assembly), the code to invoke a function LED with two parameters, perform some operation and return could be quite large and not particularly pretty. And, of course, the function itself still has to be written. > > And Dan's point needs to be considered. If timing requirements are > > important, ASM is predictable, nothing is hidden away in a library, > > every instruction cycle is on display. > > Again, you don't *have* to hide stuff in a HLL library, if every cycle > matters you simply don't. If every cycle matters, C is not the way to go. I was just messing around with a PIC Pong game where every instruction counts toward timing the video. Definitely not a place for a high level language! We can debate this forever - you're still going to win. My first computer language was Fortran; ASM didn't come until much later and then it was the only thing available. If Fortran hadn't been available I doubt I would have ever gotten started with programming! I don't really have a preference for a language for the PIC. The only language I really enjoy is Pascal and just as I was about to finally use it the demo period expired! It looks good, however : http://www.picant.com/p2c/p.html But, again, it would be non- portable and device limited. > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: www.voti.nl/hvu |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 5 21:15:00 2004
|
----- Original Message ----- From: rtstofer <> To: <> Sent: Friday, November 05, 2004 10:07 PM Subject: [piclist] Re: New ASM vs C > > > > > > It is. Been there, done that. But when you want to abstract the > next > > level of HLL (procedure/function, local variables, optimization of > > constant expressons, ...) things get very ugly. Been there, tried > that, > > ended up writing a compiler instead. > > Absolutely true! But, it isn't the language so much as the > hardware. No data stack, no indirect or indexed addressing (and I > don't count FSR and INDF as indexed - what a kludge!), no registers > (using RAM through W and calling it a register hardly qualifies) Registers, RAM what's in a name. The fact is that accessing these registers does not impose a performce penalty. It's not like a Z80 where operations involving special registers like A and B are faster than A and (RAM). The FSR / INDF kludge that you refer to only looks like a kludge because the assembler is so crap. Using INDF does not impose additional overheads like using IX on a Z80. You should take another look at the PIC from the point of view of "incomplete" instructions. The PIC assembler could have been written to provide things like ADD R1,R2 ADD R1,#3 ADD R1,(R2) and the generated machine code would have been variable length with variable execution times. Think of W as an operand register that may or may not need to be setup by a prefix instruction. The fact that some compilers try to use W as an accumulator only confuses the issue. Look at the MSP430. The assembler hides the strange way some of the registers have special meaning yet MSP430 assembler programmers just view this as an addressing mode that has been put to good effect. The same is really true of FSR/ INDF. If you want to blame anybody for the "kludge view" blame the people that wrote the crappy PIC assembler. > and > limited memory (16F series) makes things like parameters, local > variables and functions very difficult to write. C doesn't improve > the hardware, it just hides the nasty details. The emitted code is > just as ugly, if not more so, than if it was written in ASM. Generated ugly machine code is not the point. Maintainable source code and a reliable error free executable is the point. It does not matter what the machine code looks like because you generate it each and every time from the HLL source code. I think that one of the problems here is that the C language is trying to impose a specific style of implementation where it is not required or appropriote. Stack based processing was originally more about implementing a simple compiler on slow hardware (PDP-11) rather than generating the best code. For many years people prefered using Fortran to C because it generated better code. > And, when it comes time to port? Well, there's ANSI C, and then > there's C. Some implementations are better than others. CC5X (free > version), for example, can't handle complex (difficult, not > imaginary) expressions and refuses to accept function pointers in > arrays (among other problems). So, instead of using function > pointers in my scheduler, I had to use a case statement. XCSB supports multitasking directly. > I wasted 4 hours with PIC C (demo version) the other day trying to > offset the code origin and reserve the first 3 addresses for my boot > loader. Complete waste of time - as near as I can tell it can't be > done since they use a long jump as the first instruction seqence. > It is possible in PIC C Lite because I have done it and both > versions purport to use the same 'powerup.as' code - I gave up > before getting it to work. Something as simple as setting the code > origin and the compiler gets in the way. Have you considered that this limitation might be because you are using the demo / lite versions. Let's be fair, some things you [compiler writer] don't want the hobbyist doing otherwise some "professionals" don't need to buy the commercial product. Think of it like this: you release a product that is limited to generating 2k of code, someone comes along and generates a program that consists of 4 tasks each of 2k relocated to a 2k code page and hey presto you fill a 16f877 with 8k of code (which breaks the compiler restriction) > And so it goes, every implementation has warts. The only universal > constant is the assembler provided by the manufacturer - the common > denominator. Everything else is non-portable or limited to a > specific series of devices. What if you want to move to the latest > whiz bang micro and your compiler writer hasn't gotten around to > it? It's pretty certain that MPLAB will support the device as soon > as it's available. > > I do like C and I use C from time to time. When I was writing a > cooperative multitasking project, C was the way to go. A couple of > days ago I was writing a simple program to get data from the serial > port and feed it out using the SPI protocol. Given the tools at > hand, ASM was the easiest way to get it done. There are XCSB users developing timing critical software directly in XCSB without the need to resort to assembler. > It just doesn't matter - whatever gets the project complete. I came across your FPGA postings the other day, interesting. I wish I had time to play with these myself :-) I look forward to reading about your experiences with these. If you're going to go the whole hog and invent your own instruction set you might want to look at the XCASM meta assembler. Send me a private email if you'd like to discuss special pricing :-) Regards Sergio Masci htp://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 5 23:55:00 2004
|
----- Original Message ----- From: rtstofer <> To: <> Sent: Saturday, November 06, 2004 3:41 AM Subject: [piclist] Re: New ASM vs C > Sergio, > > I wandered over to your site the other day before I started that > small app. I wanted to look at your XCSB product since you have > mentioned it here before. In reviewing the online documentation I > couldn't see a way to offset the origin so I moved away. I am > reasonably certain it can be done, I just couldn't find it. Hi Richard, Yes it's simple. You just add a ".org" statement to the "startup.asm" file. This is disabled in the LITE edition otherwise it would be possible to circumvent the license restrictions (as I mentioned in my previous post). > I'm having a ball implementing the P4 p-code on an FPGA. Turns out > that I want a display of the top-of-stack and next-on-stack values > and I bought one of those Maxim MAX6954 16 digit LED display drivers > with SPI interface. This is a fairly complex device and I thought > that writing the initial drivers inside the FPGA would be difficult > so I designed a 16F628 and MAX3233 into the PCB so I could play with > the display from Hyperterminal until I was certain I understood the > functionality. > > It will plug into one of the expansion ports of the Xilinx Spartan-3 > Starter Board. I'll just have the state machine send the stack > values each time they are modified. The actual values are in memory > with a couple of cache registers to mirror the contents. Should > work fine but the PIC will simplify the development. At the moment > the machine is running at 50 MHZ and can execute some instructions > in a single cycle. There's a ton of work left to do... Not to > mention writing the OS and file system > > Richard This sounds really fascinating, I really wish I had the time. Silly question but why do you want to be able to relocate code on the 16F628? It can't program itself so you can't use a bootloader with it. Were you planning on using a 16F88? Regards Sergio Masci htp://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
RE: Re: New ASM vs C - Wouter van Ooijen - Nov 6 3:19:00 2004
|
> I am proficient enough in ASM that I can write an app in ASM > in about the > same amount of time I'd use to write in a HLL. I'm not an > expert by any > stretch of the term, but I can hold my own. > > Bottom line..., I'll probably just stay with ASM, and not > worry about > HLL's any more unless the customer specifically wants the > code in a given > HLL. Whether *you* are more comfortable with HLL or asm is hardly an argument, unless you are the only programmer available for a project. If you had real experience in both (let's say a few years full time programming in asm and the same in HLL) I would value your opinion higher, but still not conclusive. (Note: I don't have the required years of asm programming to add sufficient weight to my opinion). Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 6 11:10:00 2004
|
----- Original Message ----- From: Wouter van Ooijen <> To: <> Sent: Saturday, November 06, 2004 8:19 AM Subject: RE: [piclist] Re: New ASM vs C > > > I am proficient enough in ASM that I can write an app in ASM > > in about the > > same amount of time I'd use to write in a HLL. I'm not an > > expert by any > > stretch of the term, but I can hold my own. > > > > Bottom line..., I'll probably just stay with ASM, and not > > worry about > > HLL's any more unless the customer specifically wants the > > code in a given > > HLL. > > Whether *you* are more comfortable with HLL or asm is hardly an > argument, unless you are the only programmer available for a project. If > you had real experience in both (let's say a few years full time > programming in asm and the same in HLL) I would value your opinion > higher, but still not conclusive. (Note: I don't have the required years > of asm programming to add sufficient weight to my opinion). > > Wouter van Ooijen Here is something a bit more tangible. you write a program in assembler and you associate a meaning with a label. You create several labels and each has its own meaning. You write your code so that these labels interact with each other. You are responsible for ensuring that the interaction is consistent and correct. The labels do not carry enough information for the assembler to verify how you use them or how they interact. You embed many comments in your source code to remind you what you are doing with these labels, the assembler cannot understand these comments and cannot use them to verify your use of the labels. With a High Level Language (HLL) however, you assign each label many attributes by virtue of your definition of the label. The HLL compiler could simply complain when it finds inappropriate use of a label and inexperienced programmers would nod sage like and see the benefit of the HLL over assembler "ha silly mistake, the compiler just saved me a few hours of debugging". Nowadays however we expect the HLL compiler not to complain but instead to use the context that label is presented in to produce code appropriate to its use i.e. the way the labels interact. Largely because of this "well if the compiler can see it's wrong and it knows what it should be so it should automatically correct it for me" attitude many people have lost the plot (or were never told the plot in the first place). Programming using a HLL compiler is not just about describing a problem as an algorithm in a high level form so that it gets translated into machine code, it is also about controlling the way the compiler understands your description. If you can show the compiler what you are trying to do rather than just give it a sequence of statements to translate then the compiler should be able to generate better code than you. if you write: A = A + 1 The compiler should understand this to mean increment A by 1. Some compilers go through the statement mechanically and just generate: movf A,w addlw 1 movwf A Other compilers will generate: incf A The assembler programmer will simply write: incf A But when the program changes some time in the future and A needs to accommodate numbers bigger than 255, the HLL programmer will simply change the type of A whereas the assembler programmer must work though all the source to ensure that A is now used appropriately. This is the maintenance aspect of the work. The assembler programmer may not even have finished writing the program yet he must go back and maintain otherwise fully working and debugged sections which the HLL programmer can leave alone. I often grimace with frustration when I hear the argument that high volume production justifies using assembler rather than HLL. The argument goes: "We are going to produce 10,000 widgets. We can save $0.25 per unit if you use PIC X instead of PIC Y. We can use PIC X instead of PIC Y if we program in assembler instead of a HLL". Yet the reality is that it will take a good HLL programmer less time to program the PIC than a good assembler programmer. If you put heavy constraints on the assembler programmer such as you only have 1K of code space instead of the 2K you allow the HLL programmer then you are making it even harder for him to meat the same deadlines as the HLL programmer. So lets say it takes your assembler programmer a month longer to write the code and lets say you are paying a reasonable salary say $50,000 / year. How much have you actually saved? The crazy thing is that even if you make a small profit using this cost cutting exercise people seem to shut their eyes to the other very important aspects of time to market and reliability. If you get your product out one month earlier, that's one months extra sales, that's one month lead on the start of your next project, a jump on your competitor. If you produce a reliable product that's less of a risk of a product recall, an improved standing in the market, less of a risk of people suing you and less of a risk of you being stuck with 10,000 units that no one will buy. C is getting a bad reputation in the low end embedded market. Admittedly some of it is deserved but the majority of the problem can be laid squarely at the door of the compiler writer / vendor. So programmers trying to use a C compiler on a PIC find that it is crap and since C is the king of efficient HLL's automatically assume that everything must be crap (especially BASIC which has a reputation for producing slow executables and allowing programmers to write spaghetti code). Conclusion: Assembler may be the only option open to you but if you have the opportunity try to learn to use a HLL compiler effectively. If you are using a crap compiler then make a note of your problems (things wont improve if we don't know about your problems) and look for a better compiler. <shameless plug> the following XCSB source: proc fastcall fred(ubyte *ptr) *ptr = *ptr + 1 endproc proc main() ubyte X fred(&X) fred(&X) endproc will now generate the following assembler fred incf X return main call fred call fred </shameless plug Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 6 12:04:00 2004
|
----- Original Message ----- From: rtstofer <> To: <> Sent: Saturday, November 06, 2004 5:49 AM Subject: [piclist] Re: New ASM vs C > > > > This sounds really fascinating, I really wish I had the time. > Silly question > > but why do you want to be able to relocate code on the 16F628? It > can't > > program itself so you can't use a bootloader with it. Were you > planning on > > using a 16F88? > > No, I wasn't clear about the requirement. For me, it is easier to > develop code on a 16F877 with a boot loader. I have a prototype > board all set up for this and, given a choice, I will use this > first. Its really just the MiniSumo Mark III chip preprogrammed > with a boot loader and I use the related BotLoader application for > downloading. > > When the code was functioning I just changed the device type which, > through conditional assembly, cleaned up the starting code and > changed the port initialization. I then programmed a 16LF628 so I > could operate at 3.3V to match the requirement of the display driver. Hi Richard, Just so that you know, I have a bootloader for the 16F88 (it's part of the XCSB Standard and Pro edition packages). It uses TeraTerm as the uploader from Windoze or you can just cat to it from Linux. > The 18 pin device is a bit of overkill as I don't use any of the > PORT A pins but I have a few on hand and a bit of experience with it. > > I have no issue with limited functionality of demo software and I > have no issue paying for software I use. But the limiting factor > for my little project was the requirement to accomodate the boot > loader. There were alternatives, I just took the easy way out and > copied/pasted ASM code from other projects. > > I really did want to use a HLL, mostly due to the debate we had a > week of so back. I stumbled around for a few hours, threw up my > hands in surrender and went back to ASM. > > The other day I was thinking about the meta assembler idea you > mentioned. I thought I might need to write one as the P4 compiler > emits p-code in text form. The interpreter for the CDC 6600 is > written in Pascal (for the distribution kit only, I suspect) and > assembles the code during loading. I stripped out big chunks of the > interpreter and changed the assembler component to emit a listing > with address, opcodes (and related fields) and the original assembly > text. I also added the ability to generate the text required for > initializing the internal BlockRAM of the FPGA. Fun-o-meter needle going into the red :-) Out of curiosity could you point me at a description of the CDC6600 instruction set. > At the moment code > is downloaded to the FPGA when the device is initialized and is > retained in the Platform Flash PROM. Oh, and all of this using Free > Pascal on my Fedora Linux box! A very nice Linux, by the way. Really? what is it about Fedora that you like? I'm a SuSE die-hard myself but I'm always interested in hearing other opinions. > I highly recommend the Xilinx Spartan 3 Starter Board as a place to > start with FPGAs. It's not the only board I use but it is the one I > am using for this project. At about $100 the price is more than > fair! I'd really love to play with this, so much so that I lurk on the FPGA group :-) But being reallistic the Spartan 6 or 7 will probably be out before I get around to it :-( Regards Sergio Masci htp://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 6 21:12:00 2004
|
----- Original Message ----- From: Phil Seakins <> To: <> Sent: Sunday, November 07, 2004 1:38 AM Subject: Re: [piclist] Re: New ASM vs C > > At 02:10 AM 7/11/04, sergio masci wrote: > ><shameless plug> > > the following XCSB source: > > proc fastcall fred(ubyte *ptr) > > *ptr = *ptr + 1 > > endproc > > proc main() > > ubyte X > > fred(&X) > > fred(&X) > > endproc > > will now generate the following assembler > > fred > > incf X > > return > > main > > call fred > > call fred > ></shameless plug> > > Hmmm, in this instance, shouldn't the code produced be more like; > > main > incf X > incf X Hi Phil, If you define "fred" as inline then yes this is what you get. If you define it as "fastcall" then you get what I posted. The important thing to note here is that "ptr" is converted to a direct address access (no going through FSR/INDF) which is embedded in the function "fred" because the compiler sees it's safe to do so. Yes "fred" is simple in this case but that is because I was trying to highlight what was happening. If "fred" were much more complicated inlining might be out of the question. Anyway try getting the same level of optimisation out of an ANSI C compiler :-) Regards Sergio Masci |
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 6 22:03:00 2004
|
----- Original Message ----- From: rtstofer <> To: <> Sent: Saturday, November 06, 2004 5:19 PM Subject: [piclist] Re: New ASM vs C > > > > Here is something a bit more tangible. > > > > you write a program in assembler and you associate a meaning with > a label. > > You create several labels and each has its own meaning. You write > your code > > so that these labels interact with each other. You are responsible > for > > ensuring that the interaction is consistent and correct. The > labels do not > > carry enough information for the assembler to verify how you use > them or how > > they interact. You embed many comments in your source code to > remind you > > what you are doing with these labels, the assembler cannot > understand these > > comments and cannot use them to verify your use of the labels. > > > > With a High Level Language (HLL) however, you assign each label > many > > attributes by virtue of your definition of the label. The HLL > compiler could > > simply complain when it finds inappropriate use of a label and > inexperienced > > programmers would nod sage like and see the benefit of the HLL over > > assembler "ha silly mistake, the compiler just saved me a few > hours of > > debugging". Nowadays however we expect the HLL compiler not to > complain but > > instead to use the context that label is presented in to produce > code > > appropriate to its use i.e. the way the labels interact. Largely > because of > > this "well if the compiler can see it's wrong and it knows what it > should be > > so it should automatically correct it for me" attitude many people > have lost > > the plot (or were never told the plot in the first place). > > On of the things I like about Pascal is the fact that it is strongly > typed. The compiler expects my to prove that I know what I am doing > and that we agree on the interactions. > > C will take my word for the fact that I know what I am doing with > pointers. Sometimes, this is not the case... Ok then use PASCAL or JAL. > Programming using > > a HLL compiler is not just about describing a problem as an > algorithm in a > > high level form so that it gets translated into machine code, it > is also > > about controlling the way the compiler understands your > description. If you > > can show the compiler what you are trying to do rather than just > give it a > > sequence of statements to translate then the compiler should be > able to > > generate better code than you. > > > > if you write: > > A = A + 1 > > The compiler should understand this to mean increment A by 1. Some > compilers > > go through the statement mechanically and just generate: > > movf A,w > > addlw 1 > > movwf A > > Other compilers will generate: > > incf A > > > > The assembler programmer will simply write: > > incf A > > But when the program changes some time in the future and A needs to > > accommodate numbers bigger than 255, the HLL programmer will > simply change > > the type of A whereas the assembler programmer must work though > all the > > source to ensure that A is now used appropriately. This is the > maintenance > > aspect of the work. The assembler programmer may not even have > finished > > writing the program yet he must go back and maintain otherwise > fully working > > and debugged sections which the HLL programmer can leave alone. > > > > The is especially problematic on machines that are almost strictly > byte oriented. Changing from an 8 bit definition to a 16 bit is a > MAJOR PITA. > > > I often grimace with frustration when I hear the argument that > high volume > > production justifies using assembler rather than HLL. The argument > goes: "We > > are going to produce 10,000 widgets. We can save $0.25 per unit if > you use > > PIC X instead of PIC Y. We can use PIC X instead of PIC Y if we > program in > > assembler instead of a HLL". Yet the reality is that it will take > a good HLL > > programmer less time to program the PIC than a good assembler > programmer. If > > you put heavy constraints on the assembler programmer such as you > only have > > 1K of code space instead of the 2K you allow the HLL programmer > then you are > > making it even harder for him to meat the same deadlines as the HLL > > programmer. So lets say it takes your assembler programmer a month > longer to > > write the code and lets say you are paying a reasonable salary say > $50,000 / > > year. How much have you actually saved? The crazy thing is that > even if you > > make a small profit using this cost cutting exercise people seem > to shut > > their eyes to the other very important aspects of time to market > and > > reliability. If you get your product out one month earlier, that's > one > > months extra sales, that's one month lead on the start of your > next project, > > a jump on your competitor. If you produce a reliable product > that's less of > > a risk of a product recall, an improved standing in the market, > less of a > > risk of people suing you and less of a risk of you being stuck > with 10,000 > > units that no one will buy. > > I would never tout using a HLL, especially C, as an enhancement in > reliability. Unless the programmer is willing, and able, to go > through the library functions, line by line, the manufacturers > reputation rests in the hands of the compiler writer. I have > noticed that the ASM listing produced by some C compilers does not > include library code. How in the world can a program be validated > when 90% of the code isn't visible except as machine code from the > HEX file? I would say that it is an enhancement to reliability because the compiler is able to detect many stupid mistakes that I might make at assembler level. The question is not that C allows you to write reliable code but that a HLL will allow you to write code that is more reliable than if you wrote it in assembler. If you wish to use ADA, PASCAL or ALGOL instead of C, fine by me. Actually, if you want to use assembler that's fine be me too. I'm just trying to point out that a compiler can do a hell of a lot for you that an assembler cannot. Ironically most of the libraries will be written in assembler in order to achive maximum optimisation :-) XCSB uses libraries written in XCSB in order to take advantage of its own optimisation. > And, speaking of validation, how are these compilers tested? Are > there any industry standard tests? I know there are ANSI C > validation suites but I don't imagine they are relevant for embedded > applications. I guess we could make the assumption that the > compiler with the most users will be the better choice assuming the > vendor corrects the issues that arise. And, just because the > application function under version 1.xx of the compiler doesn't mean > it is still functional under version 2.xx. Having the latest and > greatest version is not always a plus! Your arguments against using a "particular" C compiler are very valid. But this is like a woman who has only known a few men swearing that all men are B*stards. If you find a problem with a particular C compiler don't just get annoyed and junk it. Tell us about it. By publicising the problems you either force the compiler writer / vendor to fix the problem or you help the better compiler writer / vendor to rise to the surface. Either way it cannot hurt the rest of use. > There is little debate about time to market, engineering economics, > clarity of expression and those issues. The HLL has it hands down > in productivity but I don't think I'll concede to reliability. > > And, just before I concede portability, I was just awakened to the > fact that the stack isn't always 8 elements deep. The 10F series > can be programmed in C but the stack is only 2 elements deep. Now, > more than ever, the library code can become a liability. If we > assume 1 level of the stack is for interrupts then there is only 1 > level for program flow. That will be a challenge for the ASM > programmer as well! Actually XCSB only uses the hardware stack for table lookup and if explicitly told to use it with the "fastcall" keyword. Otherwise the function call depth in XCSB is only limited to available RAM. > > > > C is getting a bad reputation in the low end embedded market. > Admittedly > > some of it is deserved but the majority of the problem can be laid > squarely > > at the door of the compiler writer / vendor. So programmers trying > to use a > > C compiler on a PIC find that it is crap and since C is the king of > > efficient HLL's automatically assume that everything must be crap > > (especially BASIC which has a reputation for producing slow > executables and > > allowing programmers to write spaghetti code). > > > > There are problems with every implementation, somewhere. There is > always a limitation, a spot where the compiler writer's assumptions > don't match the project requirements, etc. Sometimes they are just > an irritant, sometimes they are fatal. And sometimes they are just > enough of an annoyance to cause me to throw up my hands in surrender! Ok you're right. Ultimately it's all about productivity maintainability and reliability. If you feel frustrated in any one of these areas then run, as you already obviously have. But is there no way that I can entice you over to the Dark side young Luke? > > > Conclusion: Assembler may be the only option open to you but if > you have the > > opportunity try to learn to use a HLL compiler effectively. If you > are using > > a crap compiler then make a note of your problems (things wont > improve if we > > don't know about your problems) and look for a better compiler. > > > > ASM has a very steep learning curve. The time required to get up to > speed with the instruction set and learning the 'patterns' make the > HLL very attractive. But the programmer would be well served to > understand ASM. Sooner or later the debugging gets down and dirty. I agree but you have to be careful about insisting that someone becomes a proficient assembler programmer. It might be all they need to scare them off. After all we're not just taking about professionals here. There will be a lot of hobbyists and students reading these posts. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 6 22:14:00 2004
|
----- Original Message ----- From: rtstofer <> To: <> Sent: Saturday, November 06, 2004 6:00 PM Subject: [piclist] Re: New ASM vs C > Here is a pretty good link on the machine itself: > http://www.moorecad.com/standardpascal/cdc6400.html > > The Pascal P4 project is documented at > http://homepages.cwi.nl/~steven/pascal/book/pascalimplementation.html > > The P4 compiler and interpreter source are at > ftp://ftp.cwi.nl/pub/pascal/ as pcom.p and pint.p Note how clean > the interpreter is and how easy it is to convert this to a state > machine. Not necessarily an optimal machine but it will be fun to > play with! Thanks for the links > It's no longer necessary to > be a black belt in /etc. My god, did you think this one up yourself? It's hilarious :) > I thought having the Linux tool chain would be useful for my P4 > project plus I am building up a spectrum of enviornments for my > grandson. Everything from CP/M through DOS, Win98, WinXP, NT > Server, Linux. He will need it all. Good old pip > I really just wanted to build PacMan (http://www.fpgaarcade.com/) > but I got sidetracked! Tell me about it :-) Regards Sergio Masci htp://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 6 22:19:00 2004
|
----- Original Message ----- From: Wouter van Ooijen <> To: <> Sent: Saturday, November 06, 2004 6:28 PM Subject: RE: [piclist] Re: New ASM vs C > > > So lets say it takes your assembler programmer a > > month longer to > > write the code and lets say you are paying a reasonable > > salary say $50,000 / > > year. How much have you actually saved? > > No matter which figures you put into the equation, there will be a > volume figure for the HLL /asm break-even, and above that asm will save > money. But that figure will often be surprisingly high. > > An assembler programmer can always make a program faster & smaller than > a HLL programmer can, given sufficient time. Given insufficient time > (which is much more often the case!) a HLL programmer has a much better > chance to get the program working. > > Wouter van Ooijen I don't remember the original source of this: Every assembler program can be reduced by one instruction and every program has at least one bug. Taken to its conclusion: every assembler program can be reduced TO one instruction which WILL be wrong. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: New ASM vs C - Lance - Nov 10 14:54:00 2004
|
Hi I know this age old debate has been flogged to death but as fond as I am of ASM it sucks when it comes to maths,floating point and especially polynomials. Since I frequently use maths in our applications there is little choice. Lets be honest guys... page switching is a cruel joke by Microchip as punishment for us being geeky enough to enjoy using their devices. Heathen!.. cast him out I hear you say. Lance --- In , "Paul James E." <jamesp@i...> wrote: > > All, > > Like I've said several times before, IMHO, for PIC's, ASM is the way to go. > I've tried 'C', and as has been explained here (and elsewhere), it just > doesn't give you (me) the control you (I) like. |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - Chad Russel - Nov 10 20:04:00 2004
|
--- Lance <> wrote: > Hi > I know this age old debate has been flogged to death but as fond as > I am of ASM it sucks when it comes to maths,floating point and > especially polynomials. > Since I frequently use maths in our applications there is little > choice. > > Lets be honest guys... page switching is a cruel joke by Microchip > as punishment for us being geeky enough to enjoy using their devices. Why not ask Intel where the FG register pair went? :-p > Heathen!.. cast him out I hear you say. > > Lance > > --- In , "Paul James E." <jamesp@i...> wrote: > > > > All, > > > > Like I've said several times before, IMHO, for PIC's, ASM is the > way to go. > > I've tried 'C', and as has been explained here (and elsewhere), > it just > > doesn't give you (me) the control you (I) like. > ===== My software has no bugs, only undocumented features. __________________________________ |
|
|
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: New ASM vs C - rtstofer - Nov 10 23:50:00 2004
|
-> Why not ask Intel where the FG register pair went? :-p Isn't that where they hide the CPU serial number? I'll have to check the datasheet again... |
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: Re: New ASM vs C - sergio masci - Nov 11 0:27:00 2004
|
----- Original Message ----- From: Lance <> To: <> Sent: Wednesday, November 10, 2004 7:54 PM Subject: [piclist] Re: New ASM vs C > > > Hi > I know this age old debate has been flogged to death but as fond as > I am of ASM it sucks when it comes to maths,floating point and > especially polynomials. > Since I frequently use maths in our applications there is little > choice. There is most definitely a choice. The XCASM assembler has built in high level code generator capabilities. You can add an assembler source code statement of the form: .let A= B + SIN(C) And the assembler will behave as though you had compiled the statement using a high level language, converted the statement to assembler source and then inserted the source into your assembler program. BTW, XCASM also knows how to deal with floating point and long integers. > Lets be honest guys... page switching is a cruel joke by Microchip > as punishment for us being geeky enough to enjoy using their devices. No, you're looking at it wrong. Page switching allows you to make instructions smaller and faster by moving that part of the instruction which does not vary to another point in the execution stream. The real problem is that the software tools available from MC do not help you deal with the paging. The one thing that computers really excel at is doing long laborious tasks quickly. Yet we are left to deal with the complex analysis of execution flow and paging by hand. The XCASM assembler on the other hand can do the analysis for you and insert page and bank select instructions in the executable at optimal points. XCASM is the assembler used by the XCSB compiler so if you should decide to embed assembler source in your XCSB source you don't have to worry about paging since it is all done for you. > Heathen!.. cast him out I hear you say. > > Lance Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-comercial use |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: New ASM vs C -- Page Switching - Allan Lane - Nov 11 8:47:00 2004
|
Actually, page switching is a way of allowing 8-bit operands to access a lot of memory. In a device with as little resources as the PIC, it allows quite a lot of flexibility. At the price of a lot of pain, I admit. Now that we have the 18Fxxx series, hopefully it will become less and less of an issue. --- In , "Lance" <lance@i...> wrote: > > Hi > I know this age old debate has been flogged to death but as fond as > I am of ASM it sucks when it comes to maths,floating point and > especially polynomials. > Since I frequently use maths in our applications there is little > choice. > > Lets be honest guys... page switching is a cruel joke by Microchip > as punishment for us being geeky enough to enjoy using their devices. > > Heathen!.. cast him out I hear you say. > > Lance > > --- In , "Paul James E." <jamesp@i...> wrote: > > > > All, > > > > Like I've said several times before, IMHO, for PIC's, ASM is the > way to go. > > I've tried 'C', and as has been explained here (and elsewhere), > it just > > doesn't give you (me) the control you (I) like. > |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )