From: | Paul Qureshi |
Date: | 10 Sep 2001 at 22:34:22 |
Subject: | [amiga-c] Re: VB int problem (was Re: Help needed with random crashing problem) |
Hi Gunther.
>> UWORD mojo = 0;
>> UWORD intvolume;
> I would suggest to make these ULONGs since in my experience modern
> compiler deal much better with 32bit quantities (at least GCC)
I'll give it a go. The code Storm C put out using words isn't very
optimal...
>> UWORD tempvol;
> Same here and it should be local to your interrupt function.
If it's local won't the interrupt code have to put it on the stack or
something? I don't really know much about how compilers deal with local
variables. I figured if I made it global, it would be allocated early on
and it would just be referenced when needed, as the assembler code
shows it is.
>> UBYTE db = 0;
> ULONG if global. If you collect your interrupt data in a structure
> then
> things are a little bit different. In that case you could use UBYTE
> for
> db but pay attention to alignment issues. 32bit quantities are best
> alignet at 32bit. If you use smaller types you should group them to
> together to always get a multiple of 4. Use padding if that the only
> way to achieve the alignment.
I did think of doing that, but for some reason didn't. I did it for my
MHI interrupt, as I think I said, although it probably wouldn't make
much difference since everything here as the compiler uses absolute
addressing anyway.
Then again, I should really move to the small data model, as the program
is only about 36k and speed is important.
>>>> tempvol = mojo * 0.8;
>> This looks like floating point math. This is a bad idea to use in
>> an
>> interrupt.
> You don't know which FPU registers the compiler is going to use for
> the
> calculation. The RKM says exactly which registers are srcatch
> registers
> for interrupts but AFAIK FPU registers are not mentioned at all.
> Thus
> you shouldn't changed the value of any FPU register. I could imagine
> that FP0/FP1 are treated as scratch with your compiler and floats
> are
> slow (compared with ints on 68k ;-)
You make some good points. I didn't really think about using floating
point code, but now it's clear it could cause problems. Removing the
floating point code from the interrupt seems to have fixed the problem,
the program is no longer crashing.
It seems that there is a bit of an oversight in the RKMs then, regarding
floating point register use.
> You should replace your calculation with: tempvol = (mojo * 8) / 10;
> BTW, no need to use shifts. Your compiler should know best when to
> use
> which instructions.
It does seem to have optimised the mulu.w #8,d0 into a rol.w #3,d0.
I did notice thought that Storm C does miss some simple optimisations,
like saving from d0 and then loading the same variable back into it with
the next instruction, only to save it again later. That's with maximum
optimisation. I don't know if V4 is better, does GNU C pick up on that
kind of thing? There are some more complex optimisations that could have
been made too, mostly to do with register usage and loading/saving
variables.
>> > Furthermore, you should pass a pointer to a structure with all
>> > data
>> > your function needs (don't forget SysBase!) to avoid accessing
>> > global
>> > data. Then you could get rid of __saveds.
>> That's a good idea. I used that technique for my MHI interrupt which
>> was all assembler.
> Why didn't you do the same in C? Its easy ;-)
I didn't really see the point... I guess it makes things a bit neater,
grouping all the data for the interrupt together, but there is no speed
gain. The code started out quite neat and nice, but as I am returning to
uni soon I just wanted to get it finished and so I concentrated more on
getting things working than making them elegant.
>> > BTW, you shouldn't use the VERTB interrupt in the first place. Did
>> > you
>> > consider using a PA_SOFTINT port together with the timer.device?
>> > This
>> > will give you constant timing on every amiga.
>> I didn't think of that. It sounds like a better way to do things
>> though.
> If you need a working example how to use such ports I recommend a
> program of my own :-)
Thanks, I'll take a look, the RKM example code isn't bad either.
However, I just realised the obvious mistake we both made. It's
impossible to use the CIA timer, and in fact better to use the VERTB
timer which is based on the screen update. In order to use the analogue
joystick registers (which is what the interrupt does, as you can see),
you have to access the potgo register during the vertical blanking
period, then read it again at the next vblank.
>> I just thought that the VERTB interrupt would be a simple and easy
>> way to get timing on my fixed system. I didn't worry too much about
>> compatability beyond the A1200 030 I am using, TBH.
> Its not only compatibility but the timing of VERTB depends on the
> used
> screenmode. I think you know that .-)
Yeah... the analogue joystick charging capacitor doesn't vary though, so
you have to calibrate for each screen mode, with resolution decreasing
as the refresh rate goes up.
Thanks for helping out here, I'm glad I finally got this thing working!
Regards,
Paul
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Secure your servers with 128-bit SSL encryption! Grab your copy of VeriSign's FREE Guide: "Securing Your Web Site for Business." Get it Now!
http://us.click.yahoo.com/n7RbFC/zhwCAA/yigFAA/dpFolB/TM
---------------------------------------------------------------------~->
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/