Floating Point in IDE
pjv
Posts: 1,903
Hi All;
Probably this post is most appropriately directed·to PJ Monty......
Would it be reasonable to add to the SX IDE the ability to display watch values in floating point format?
I realize the are several formats; my personal application uses the format emanating from the CCS "C" compiler, and·I think it's the same as the PIC format.
Having that feature available would be a great convenience, especially if it could be had in big endian as well as little endian as I use both.
Many thanks for your consideration.
Peter (pjv)
·
Probably this post is most appropriately directed·to PJ Monty......
Would it be reasonable to add to the SX IDE the ability to display watch values in floating point format?
I realize the are several formats; my personal application uses the format emanating from the CCS "C" compiler, and·I think it's the same as the PIC format.
Having that feature available would be a great convenience, especially if it could be had in big endian as well as little endian as I use both.
Many thanks for your consideration.
Peter (pjv)
·
Comments
Boy, that is a tricky one. As you point out, the floating point format would have to be known and standardized for it to truly be useful. Aside from IEEE-754 (or whatever that standard is), there really isn't a universal standard for floating point that I know of. This means that if I add support for one floating point format, then someone else is going to come along and ask that their floating point format be supported as well. This could get ugly in a hurry. I know that if I were to add support for the CCS compiler, I would definitely have to add support for the ByteCraft compiler as well.
Furthermore, all of this is mitigated by the fact that most people are writing in either assembly or SX/B for SX based projects. While I love writing in C, I still code my SX projects in assembly, so I can't even justify doing it on my own to make my life easier. I can't rule anything out for sure, but I'm not sure how likely it is that a flaoting point watch format would be added.
Thanks, PeterM
Eventhough I have the CCS C compiler, I find its output not useful for SX operation, so virtually all my stuff is written in assembler. It would be very useful to have the floating point watch format for software development by assembler.
I suspect that the format matching the current PIC format would be quite acceptable. I believe that is used by CCS; I wonder if that's what ByteCraft also uses??
Also, is this request a difficult adventure? IF it's easy then..........
Cheers,
Peter (pjv)
-Dan
·
Whatever you do gets worked into something that is not really floating point or that bogs down the SX with a lot of code and or iterations.
Just want to use a compiler that 'does everything' doesn't mean that it will work well with everything. C was created as a lower level language with a great amout of portablity at a time when RISC were not really in the mix. I am not sure that microcontroller even need C as it isn't the kind of data crunching that my desktop does.
I suppose with a co-processer [noparse][[/noparse]I bought one, but haven't really tried it], you might want to use C. But, otherwise it seems best to avoid the floating-point and find a better way to get the kind of calculations that requires.
Am I correct?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
Your suggestion·of "finding another way" is not possible for me; floating point IS the other way.
While I agree with you that the·RAM/ROM resources in an SX are limited,·I don't agree that the SX is cycle-stretched in performing a modest number of floating point operations; it takes about 10 Usec for a FP multiply at 50 Mhz.
Please understand I'm not expounding on the virtues for C as it relates to the SX; just the opposite. My SX requirements are very much performance based, require multi-tasking as well as somewhat complicated math, so assembler is the only answer; the C compiler I have does not provide useful output for an SX environment.
I have been working (off and on) on an assembler based basic floating point package, and for that reason I requested floating point watches in the IDE, as that would be quite a help.
PJ; if this is a difficult task, I can manage without it, but if it is not TOO tough, it sure would be appreciated.
Cheers,
Peter (pjv)
Post Edited (pjv) : 9/7/2005 7:02:04 PM GMT
This is at http://www.al-williams.com. Look for the PAK stuff.
Enjoy!
kenjj
I have looked at the documentation of some of the serial I/O math co-processors, and though they do give great functionality, they are quite slow, especially considering serialling in and our the numbers. Heavens, the SX can do a whole FP multiply (10 Usec) in the time of clocking a single bit into the co-processor (100 KHz). But even if such a co-processor was fast/convenient/cheap enough, the issue of seeing the results in FP format in the IDE during debugging still remains.
It seems others are trying hard to push me into directions other than where I want to go. Basic floating point math routines in assembler I believe I can handle, so THAT'S NOT THE ISSUE;..................ALL I wish for is floating point format representation of those numbers in the IDE so I can more conveniently debug programs that USE the floating point math routines I have.
PJ; I have NO idea how difficult a task this is, but it would be a wonderful feature to have.
Cheers,
Peter (pjv)
Forgot to mention; Pearl, widely considered to be the successor of sed and awk, is easier to use, with more documentation and is more versatile. You should be able to write a simple pearl script to process your assembly files to convert your floating point numbers into a format SASM can understand. Python is another option.
Problem with all these options though is it forces you to step outside of the IDE for at least one step, perhaps this is where PeterM can step in, to provide a command line option for preprocessing that would execute the specified command line on the assembly file before passing the output to SASM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
Post Edited (Paul Baker) : 9/8/2005 2:37:10 PM GMT
NO, NO, NO!
I DON'T want another processor, another language or anything like that. I'm happy with the results from my floating point routines (that I have written so far).........I JUST want to SEE the values of the floating point numbers in the WATCH window when I'm DEBUGGING application code that uses the FP library routines.
Sorry for shouting, but I can't seem to get the point accross that my issue is NOT the FP routines themselves; just seeing their output when I invoke them.
Cheers,
Peter (pjv)
IEEE 754 floating-point format is STANDARD, though, and it would be really awesome to have that in SXKey.· Please.
Because of this thread, I too have thought about what it would take to add a plugin architecture for watches. The main issue is that aside from Peter(pjv), this is the first time I've ever seen this issue come up. When Chip Gracey designed the SxKey, he put in support for watches of the following data types:
signed and unsigned decimal from 1 to 16 bytes long
signed and unsigned hex from 1 to 16 bytes long
signed and unsigned binary from 1 to 16 bytes long
fixed length strings
zero terminated strings
It's not like there are tons of other data formats that really need to be displayed. The whole idea of adding floating point support to the list of supported watch types is a bit tenuous since the key is designed to debug at the assembly level.
Adding a plugin architecture is an interesting idea, but I doubt it would get used for much more than than adding floating point watch support by Peter(pjv). It would also open up a whole Pandora's box of potential problems since someone could write a badly coded watch plugin that causes the IDE to become unstable or crash. You then get into the whole issue of who is at fault, etc, and cause tech support to go crazy trying to diagnose problems caused by the 3rd party plugins. Yikes!
Thanks, PeterM
Well, it appears your concerns about standards are well founded. I checked into the CCS FP format, and unfortunately it IS different from the IEEE 754 standard.
IEEE has: bit 31 sign; 30:23 exponent offset by 127; 22:0 mantissa
CCS has: bit 31:24 exponent offset by 127; 23 sign; 22:0 mantissa
Can anyone offer the formats of the ByteCraft and PIC standards??
Ah!!!! The beauty of standards............. there are so MANY to choose from!
Cheers,
Peter (pjv)
I still maintain it would be a great benefit to have a checkbox and command line entry form to provide textual preprocessing of the assembly language file where the output is·directed as input to SASM. (via python/pearl/sed/awk or any other·text manipulation program, a preprocessor only manipulates text to an final output state to then be compiled by another program, it does not do any compilation itself, think of macros on steroids)·
We use to provide these types of redirect hooks all the time when I was programming on the SGI, the users demanded the ability to·cook raw datasets of >100Gbytes down to a subset that they were concerned with. They were working with USGS GIS databases to·deliniate·the exact coastline of an estuary to model tidal and sedimentary flows.·One such·dataset included the entire coastline from Maine to the NC/SC border but they wanted to extract only the·data points that were within the Chesepeake Bay, Hudson Bay,·Albemarle Sound,·or whatever particular estuary they were studying.·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
Post Edited (Paul Baker) : 9/8/2005 8:27:00 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
The day you're boiling down 100 GB of data to feed to an SX, give me a call so I can tell you to buy a different CPU. Just kidding. Seriously though, the idea of adding a full blown pre-processor (or even a hook to allow a pre-processor) is one of those things that sounds good on paper but will likely end up getting used by one or two people. As it is now, the SX assembly language supports macros, and SASM supports include files. Personally, I don't think many people use either of these pieces of functionality.
I also added support for displaying hard coded (or calculated) variables and constants in user assembler messages as well as the "Top File" functionality to make using "include" files easier. I have documented both on this forum in the past. Again, I don't think a single person replied saying they used these features or that it had made their life easier. There also seem to be a lot of people who don't even use the hardware debugging capability that makes the SX such an awesome chip in the first place.
I know I sound like either a broken record or a stick in the mud, but the fact is every feature request has to be looked at in the big picture to see if the time expended makes sense for the bulk of the users. I once had someone who was very insistent that the IDE shouldn't have to save source files prior to assembly, but instead just use a copy hidden in another directory. After numerous emails back and forth, it turns out the real reason he wanted this was because he used version control software and wanted to:
1- Make changes to the source
2 - Assemble it
3 - Burn a chip
4 - Not have the version control software require him to check it back in because the time stamp had changed.
In other words, he wanted to work around their version control software. It just doesn't make sense for me to add a feature so someone can "trick" the version control software, especially since the whole point of version control software is to have a record off every change made, not just the ones you think are important.
I'm not saying that your request is of this nature, Im just using it as an example of the way different people think different features are really important. Perhaps a pre-processor (of a hook for one) will be added in the future. It really depends on how many people start chiming in and requesting it.
Thanks, PeterM
PS - I think your idea for outputting floating point data to an LCD is a really good one. In fact, I would go a step further and dedicate a separate SX to the task of receiving data via some serial interface and displaying the formatted data. That way, you'd use less I/O on the main chip and would just have to write a small routine to send data over a serial connection, thus taking up less resources on the main SX. I have debugged tons of assembly code on the 6502 and 68HC11 processors without any debugging hardware by just having a set of dedicated routines that output formatted numeric data on an attached LCD. It's basically the "printf" of the embedded world.
Are you able to share your fp routines ? I'd love to check'em out.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
Product web site: www.sxvm.com
Available soon!! Video overlay(OSD) module...
"I'm a man, but I can change, if I have to, I guess"
Red Green
·
AGAIN, I don't want to add any instructions (often memory already very full) or hardware (often many/most pins used) or machine cycles (often already squeezing out the maximum).
What you suggest (display on an LCD) will not help much if SEVERAL intermediary numbers in an FP calculation want to be observed. It's just not practical.
What I do presently is show the FP numbers in their 8 character hex format (little endian) and then launch some "FP Converter" window, punch the hex values in and observe the decimal equivalents; FOR EVERY VARIABLE OF INTEREST. WHAT A PAIN! (but not unworkable).
It would be SOOOO much nicer if on breaking they would be displayed in the desired format to begin with.
PJ; only if it's no too difficult, and only YOU can answer that.
Cheers,
Peter (pjv)
While a number of the routines are functioning, I'm not ready to consider a general release until I'm farther along, and that will still be a while.
Cheers,
Petr (pjv)
pjv, I don't know what else to say, your present method would likely have to do. Your feature request would likely also fall into the catagory of the preprocessor hook: a feature used by only a handful of people (unless perhaps you release your code so that it becomes a standardized method of FP, but they likely wouldn't add the feature until standardization. A cart before the horse situation for you). Do your FP functions occupy the entire SX codespace, or are the other routines in there that are filling up the SX?
····· My only other suggestion is creating a program on your PC that hooks the Serial port (and sends a copy of traffic downstream so the IDE still functions) and listens for debug data to fill a dialog box (in a program you create) with the formatted data. This is a major pain to do, and I don't know how easily it can be done (or if it is even possible) on the current Windows systems. I know it was possible with DOS, Win 3.1 and 95, because I wrote TSR programs that hooked the keyboard to "wakeup" the program. But Microsoft changed the serial com stuff in 98 and XP to reduce the number of security holes in the system. This also entails enticing PeterM/Parallax to provide the serial com protocol between the IDE and SX. Like I said, I fear you may be stuck with your current setup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
Post Edited (Paul Baker) : 9/9/2005 8:55:14 PM GMT
Yup, I'm stuck in this present mode (tolerable by default, but undesirable) unless PJ can find the time and/or interest to add that FP format to the watch window.
Cheers,
Peter (pjv)
I would be willing to pay a one-time cost of $100.00 to you for the community to have IEEE floating-point WATCH in SXKey.· That's IEEE 754 32-bit single and 64-bit double precision.· Perhaps·$100.00 is laughable, but·maybe others in the SXKey world would be willing to contribute also.
Steve
·
I'd join you in that, however, and, here comes PJ's difficulty, I would like also to have the CCS format as per my earlier post.
I imagine that creating of several formats; IEEE/ByteCraft/CCS/PIC; would be only slightly more difficult than a single format. But then, that's only conjecture on my part.
I re-post the IEEE and CCS formats here:
IEEE has: bit 31 sign; 30:23 exponent offset by 127; 22:0 mantissa
CCS has: bit 31:24 exponent offset by 127; 23 sign; 22:0 mantissa
Can anyone help by posting the formats for ByteCraft and PIC floating point representation please.
Cheers,
Peter (pjv)
Post Edited (pjv) : 9/10/2005 8:12:22 PM GMT
What project are you doing where the floating point watch format would benefit you? Do you have a floating point assembly library you're planning on releasing to the general public? That's something that would really be valuable to have. I know a floating point library is something I'd like to have.
Thanks, PeterM
Post Edited (PJMonty) : 9/15/2005 5:54:35 AM GMT
Well, I'll step up to the plate.....
IF you will make one or more of the appropriate (standard IEEE754/CCS/ByteCraft/PIC to be selected) Floating Point representation available in the IDE, then I will make available for non-commercial public hobby use (don't want any legal hassles, and I might want to charge for commercial use) MY basic set of FP operations compatible with my selected format: add, subtract, multiply, divide, convert-to-integer, convert-from-integer.
Please be advised that it will be a while before it is all completed as presently I have a LOT on my plate.
Pardon me for appearing insensitive, but I have NO IDEA as to what's involved or how difficult your task is, it would be of great assistance to me if you could get yours done before I do more on mine.
Also, judging by the lack of response to my request for others' input in regard to ByteCraft and PIC formats, I'm wondering how many folks would actually use the FP routines......it's not worth going to a lot of trouble if no one is truly interested.
Cheers,
Peter (pjv)
http://www.micromegacorp.com/umfpu-v2.html
But on the other hand, if someone wanted to debug floating-point routines it would be handy to have.
·
·· That chip is also available directly from Parallax...
http://www.parallax.com/detail.asp?product_id=604-00030a
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
You were wondering if people are interested in floating point routines.
I guess the indication of this is the availability of so many different FP coprocessors
that are serial. This means people are willing to buy a helper chip even at the rate of
serial comms to be able to have FP math added to their micro-processor.
Thus do not worry there are enough people interested. I for one would be
very interested since I am trying to do some DSP work with the SX and
the obstacle is that there is no FP math.
Regards
Samuel Mishal
·