64-bit division

[Manfred]

Well, I'm getting old, and as you surely know, we old guys tend be get used to our own ways of doing things! http://www.picbasic.co.uk/forum/images/smilies/wink.gif

Thank you a lot for all your help, but it simply seems too complicate to have all that looooong assembly code put in, just to do one single division! Reconfiguring my PC to be able to install PBP in the default configuration, and then learning to use the new programs, and so on, would simply take FAR too long. I want to get my project going soon, instead of embarking in a new project of PC reconfiguration, learning to use a new programming environment, and who knows what else.

So I have totally turned around the way I calculate the value I need. Instead of the routine that required the 64 bit division to arrive at the final 32 bit tuning value I need for my DDS, I prepare the data in 16 bit chunks and calculate the 32 bit tuning value as the last step in the process, using PBP's "*" and "**" operators. In doing so, I loose some tuning range, and some tuning resolution, compared to the method that needs the 64 bit division. But both of these losses are acceptable for this particular project, so I will keep this for now.

In the future I will probably do more demanding projects using a DDS, and at that point I will get back to needing multibit division... But based on the newly acquired experience, I will then use an 18-series PIC, so I can use PBP's 32 bit math, which should allow enough tuning range and resolution for even quite high requirements, using the same algorithm I implemented a while ago.

By the way, the configuration of my PC has evolved from the very first PC I owned, almost 30 years ago, and that's why it doesn't conform to modern Windows practice. I use a large quantity of specific programs , many of them written by myself. Over the years, I have added to this setup, and transferred it from each PC to the next more modern one.

Any attempts I have done to set up a new system on a new PC, and getting everything to work there, have proven to take so much time that I threw the towel before getting anywhere close to finishing. That's why I still use my old configuration.

Thanks again. I have learned that apparently there is no simple way to use PBP's 16 bit math to create 32 or 64 bit math, and so it's better for me to use a workaround.

[mackrackit]

Using note pad is cool. And to talk about non standard setups I mostly run on Linux and either use Emacs or gEdit for code writing.
I just figured you were a newb that is why I assumed you were using Micro Code Studio ... Sorry.

When you do start using 18F's MPASM will be required. It cam be evoked from the command line from just about anyplace. When you get to that point and maybe need some help we will be here.

[Manfred]

I should not have much trouble using MPASM. I just tried it with the present version of my program, and it works well. It only reported that strange error when there was the n-bit math code present.
Without that code, it assembles my program well, but still reports over 200 messages about crossing page boundaries. I hope these messages can be disabled somehow, because they make any real error messages scroll out of the window AND out of the screen buffer!

I guess that with enough time, things will fall into place.

[mackrackit]

This should help
http://www.picbasic.co.uk/forum/showthread.php?t=40

[Manfred]

Yes, it helps! Now the hundreds of useless messages are gone!

But one problem leads to the next: With PM, I edited the include file for the specific PIC to get the configuration word I need, without having to edit it in the PIC programmer every time. But with MPASM, I get the default config word, and have to edit it! I tried adding directives for the assembler to use the config word I need, but so far this has only led to errors.

Other than that, MPASM is giving the exact same output as PM. So, as long as I still use only 16F devices, I don't see a good reason to use MPASM at all! Is there any?

[mackrackit]

In the same inc file that you set the configs for PM is where you set them for MPASM . Second set of configs.

If you are using 16Fs and straight PBP then PM is fine.

[Manfred]

Oh, stupid me! It even SAYS in the file that the first set is for PM and the other is for MPASM! I didn't notice that... Now it works fine.

Let's blame it to my old age!

Thanks again!