Qwerty.55 wrote:
snprintf isn't defined in the current libraries, which is precisely why I was asking.


No sprintf either? No variations of printf whatsoever?

z80man wrote:
I think I meant there to return only a pointer not the entire array. Or if I'm wrong it should be marked as static. And what printxy() is, is a Prizm-OS syscall. There is no snprintf() yet and if there was it would have to contain printxy() unless a new text routine was created which is unlikely.


You did return a pointer, which is why it won't work. You must *never* return a pointer to something created on the stack. As soon as the function returns, *all* of the data you put on the stack in that function is no longer valid and you should not have *any* pointers to it.

Marking it as static would, strictly speaking, sort of work, but it would be very bad form. Just use the heap. That's kind of the entire reason the heap exists, to allocate stuff.
kllrnohj, there's printXY() and...


...PrintXY()

</slight exaggeration>
The lack of things like snprintf is why we are working on porting newlib.
TheStorm wrote:
The lack of things like snprintf is why we are working on porting newlib.
Indeed, and which I am very much looking forward to. Are there any bits and pieces that I could help with?
Are floating point operations (+,-,*,/) defined in the PrizmSDK or does math.h need to be ported after newlib?

Also, how would one insert a stream of hex? char* array = 0x0123456789ABCDEF0123456789ABCDEF...?
Qwerty.55 wrote:
Are floating point operations (+,-,*,/) defined in the PrizmSDK or does math.h need to be ported after newlib?

Also, how would one insert a stream of hex? char* array = 0x0123456789ABCDEF0123456789ABCDEF...?
Apparently GCC supports floats via software libraries if the target processor doesn't support them in hardware, which Tari taught me yesterday. I'd go with a fixed-point library for execution speed, though, like the one that I made for Obliterate. Smile Regarding your second question, something like char* array[] = {0x01, 0x23, 0x45, ...};
To be honest, speed really isn't an issue in this case, since the user is the main bottleneck and I'll be hand-optimizing whatever GCC spits out.


EDIT: What's the point of the makefile in the PrizmSDK /projects/ folder? Nothing I change in it has any effect on the compiled code.
The make file you want to change is in the /projects/yourproject/ folder, and yes changing that should change your code if you edited any of the other files. Try deleting the .o's, .bin's, and .g3a and then running make.bat again.
Qwerty.55 wrote:
To be honest, speed really isn't an issue in this case, since the user is the main bottleneck and I'll be hand-optimizing whatever GCC spits out.
At the risk of sounding like a pain in the neck, that's probably not worth your time. GCC does an extremely good job at optimizing, and I doubt the few cycles you could save with painstaking hand-optimization are worth the many hours it would take.
KermMartian wrote:
Qwerty.55 wrote:
To be honest, speed really isn't an issue in this case, since the user is the main bottleneck and I'll be hand-optimizing whatever GCC spits out.
At the risk of sounding like a pain in the neck, that's probably not worth your time. GCC does an extremely good job at optimizing, and I doubt the few cycles you could save with painstaking hand-optimization are worth the many hours it would take.
If you really want to do some hand optimized ASM use GCC's built in ASM functionality for the parts you really need the speed. I know Tari started a thread with some howto's related to doing that.
He did indeed mention how to properly inline ASM.
I know, but I just need the routines. It's more of a "I'm too lazy to write/debug a floating point Division routine in ASM, so I'll see if I can get a perfectly compliant routine from GCC instead" thing.
Now that I'm back from my trip...

I did write a fixed point library that does extremely fast addition, subtraction, and multiplication in well under 10 cycles. Division of course is slower and is done by dividing the divisor by 1 and then multiplying. Also both multiplication and division make excellent use of the xtrct instruction which I've been dying to use in code. The data is 1 bit of sign data, 15 bits of integer, and 16 bits of floating part. I'll post it once I finalize its integration with C++ by using operator overloading.
I have a nice set of C fixed point routines; I'd be very curious to see how their GCC-compiled and optimized forms compare with your hand-coded assembly. Smile
Hopefully the compiled gcc routines are better than the Renesas compiler routines. After looking at long long addition I almost cried due to the obvious avoidance of optimizations.
z80man wrote:
Hopefully the compiled gcc routines are better than the Renesas compiler routines. After looking at long long addition I almost cried due to the obvious avoidance of optimizations.
Considering how much excellent optimization you can get the compiler itself to perform, combined with the excellent quality of any pre-compiled libs you can find, I'd say that's definitely the case. I'd be interested in seeing some quantitative comparison if you can check it out, though. Smile
KermM, would you mind if I used your fixed point C library?
Qwerty.55 wrote:
KermM, would you mind if I used your fixed point C library?
I would absolutely love to share it. Can I assume that I didn't already share the source with you?
I don't believe I've seen it, so that must be the case.
Qwerty.55 wrote:
I don't believe I've seen it, so that must be the case.
I'll send it to you via email, then; is your profile email address sufficient? I should warn you that I originally kludged together a variety of routines I found elsewhere, then modified them past the point of recognizeability to useable status, so the licensing on them is sketchy. We're all friends here, so I'm sure it's not an issue. Smile

Edit: Sent. I should clean it up and submit it to the Cemetech archives.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement