BBC BASIC for Windows
Programming >> Assembly Language Programming >> FWAIT
http://bb4w.conforums.com/index.cgi?board=assembler&action=display&num=1318285382
FWAIT
Post by David Williams on Oct 10th, 2011, 10:23pm

I have a feeling I've asked about this before (years ago, probably).

Just read this article (Simply FPU Chap. 7):
http://www.website.masmforum.com/tutorials/fptute/fpuchap7.htm

I notice he uses the FWAIT instruction, but I don't remember seeing it in much (if at all) in BB4W FPU assembler code.

So it's not terribly important then?


David.
Re: FWAIT
Post by admin on Oct 11th, 2011, 08:39am

on Oct 10th, 2011, 10:23pm, David Williams wrote:
I notice he uses the FWAIT instruction, but I don't remember seeing it in much (if at all) in BB4W FPU assembler code.

Well, one good reason why you won't find FWAIT in any BB4W programs is that the assembler doesn't recognise it! That's because FWAIT is simply an alternative mnemonic for the ordinary WAIT instruction (opcode &9B).

The purpose of the WAIT instruction is to synchronise the execution of the main CPU and a separate (e.g. floating-point) co-processor chip. If you're writing code that must run on an ancient PC which uses an 80386 CPU plus an 80387 FPU (if such a beast is still working anywhere!) then it might be necessary to insert a WAIT in a few critical places.

As this seems unlikely, you can probably forget about it completely.

Edit: I should add that the BB4W assembler, like most x86 assemblers, automatically inserts a WAIT opcode before certain instructions, notably FCLEX, FSAVE, FSTCW, FSTENV and FSTSW. If you don't want the WAIT to be added you must use the 'no wait' versions (e.g. FNCLEX etc.).
Re: FWAIT
Post by admin on Oct 11th, 2011, 09:35am

on Oct 10th, 2011, 10:23pm, David Williams wrote:
Just read this article (Simply FPU Chap. 7):
http://www.website.masmforum.com/tutorials/fptute/fpuchap7.htm

Further to my previous reply, and having now checked out the link you gave, I'm not sure the author knows what he is talking about! According to my understanding, the FWAITs he inserts are completely unnecessary (even on an 8086/8087). For example he has this:

Code:
 fstsw ax          ;copy the Status Word containing the result to AX
 fwait             ;insure the previous instruction is completed

The assembler will automatically insert a WAIT before the FNSTSW instruction - that's the potentially important one - and there should be no need at all to add another one afterwards, as the author does.

Perhaps a degree of caution should be applied to the rest of his dissertation.
Re: FWAIT
Post by David Williams on Oct 11th, 2011, 12:58pm

Okay, thanks Richard for the reply. The information you gave is good to know.

I have actually used some of the code given in that article (Simply FPU Chap. 7), but I'll proceed with caution re. the author's opinions.

---

While I'm here, here's a recent discovery I made (or borrowed, rather) for getting integer ABS( EAX ):

Code:
cdq
xor eax, edx
sub eax, edx


You're most likely familiar with it already?

I've used it in translating this very interesting-looking piece of C code (implementation of Bresenham's line drawing algo):

Code:
void line(int x0, int y0, int x1, int y1) {
 
  int dx = abs(x1-x0), sx = x0<x1 ? 1 : -1;
  int dy = abs(y1-y0), sy = y0<y1 ? 1 : -1; 
  int err = (dx>dy ? dx : -dy)/2, e2;
 
  for(;;){
    setPixel(x0,y0);
    if (x0==x1 && y0==y1) break;
    e2 = err;
    if (e2 >-dx) { err -= dy; x0 += sx; }
    if (e2 < dy) { err += dx; y0 += sy; }
  }
}


I'm not a C programmer, of course, but even to my eyes that looks like a very efficient bit of C.

I successfully translated it to Asm (at about 4 o'clock this morning!).

Incidentally, I wanted the code not for drawing lines -- but for fast collision detection purposes.


Rgs,
David.
Re: FWAIT
Post by admin on Oct 11th, 2011, 1:58pm

on Oct 11th, 2011, 12:58pm, David Williams wrote:
Code:
cdq
xor eax, edx
sub eax, edx

You're most likely familiar with it already?

Indeed. It's not actually what's used for ABS internally to BB4W because of its inflexibility as regards register allocation (cdq forces the use of eax for input and edx for temporary storage, which isn't convenient).

Quote:
I'm not a C programmer, of course, but even to my eyes that looks like a very efficient bit of C.

I'm not too sure how one measures 'efficiency' in C. If one is very familiar with the compiler and its code generator, one might be able to 'tune' the C source code to help the code generator do a good job, but that's quite likely to mean that what's 'efficient' with one compiler is 'inefficient' with another.

Tricks like using for(;;) to implement an 'infinite' loop are unlikely to make much difference with a modern optimising compiler, I would have thought.

Quote:
Incidentally, I wanted the code not for drawing lines -- but for fast collision detection purposes.

In LBLIB I use the CombineRgn API for collision-detection (of course this won't be 'fast' in your terms). To some extent my hand was forced because LB allows you to specify whether collision-detection operates as if the objects are rectangular or elliptical (in the latter case they need to be diagonally closer together before they are deemed to have 'collided', of course) so I needed a method that could easily work for both. CombineRgn, in combination with CreateRectRgn or CreateEllipticRgn, seemed to fit the bill.

Richard.
Re: FWAIT
Post by Michael Hutton on Oct 11th, 2011, 8:22pm

on Oct 11th, 2011, 12:58pm, David Williams wrote:
While I'm here, here's a recent discovery I made (or borrowed, rather) for getting integer ABS( EAX ):

Code:
cdq
xor eax, edx
sub eax, edx


You're most likely familiar with it already?


I would think Richard is :- it's in the wiki!

http://bb4w.wikispaces.com/Simulating+assembler+macros

Michael
Re: FWAIT
Post by David Williams on Oct 11th, 2011, 8:45pm

on Oct 11th, 2011, 8:22pm, Michael Hutton wrote:
I would think Richard is :- it's in the wiki!

http://bb4w.wikispaces.com/Simulating+assembler+macros


Ah.

So it is!