PowerBASIC and the Oxford Test

[Gunther]

Oxford also has an old, venerable university. Famous graduates were John Locke, Adam Smith, Stephen Hawking or Tim Berners-Lee just to name these. No one should be able to claim that
I've taken a one-sided position in favor of Cambridge. Therefore here comes a task from the Oxford test with a detailed solution and the verification by a PowerBASIC program.

Anyone wishing to study Mathematics or Computer Science at Oxford must take and pass this test. Trust me: it's not easy without a calculator. More details and background information can
be found in the file ESTIM.PDF. I hope that I have described the problem and the solution understandably. Feedback on this would be very nice. But there is another important aspect. The
PDF file contains 2 images. Image 2 on p. 6 is a screenshot that I included as an EPS file. That's nothing worth mentioning.

But figure 1 on p. 2 is written in pure ASCII characters, so to speak. In the source text of the file ESTIM.TEX these are the lines 54 to 71. So that everyone can look at it, I've added this file
to the archive. The running application ESTIM.EXE was created with PB 3.5. I assembled the assembly language source with JWASM, but MASM and TASM will also work. Further details are
contained in README.TXT.

Of course, this program should also be tested in as many configurations as possible. I thank you in advance for the help on this.

[FORTRANS]

Hi,

   Program runs on the same two systems as those in
your Cambridge thread.  Very nicely reasoned solution
to the stated problem.  Well done.

   In the PDF, "to large" should be "too large".  And at
least one oddity in the ASM file, of no real consequence.

Regards,

Steve N.

[Gunther]

Steve,

   Program runs on the same two systems as those in
your Cambridge thread.  Very nicely reasoned solution
to the stated problem.  Well done.

Thank you.

   In the PDF, "to large" should be "too large". 

On which page is the typo?

  And at least one oddity in the ASM file, of no real consequence.

What have I not considered?

[Greenhorn]

Gunther,

on page 3, last sentence:

32 is to large, so our x from equation (7) is a bit smaller than 5. This gives us the
following inequality:

[FORTRANS]

Hi Gunther,

  And at least one oddity in the ASM file, of no real consequence.

What have I not considered?

   Well this just looked kind of odd.

Code Select Expand

GetFpu  proc  far
    fninit
    fnstsw   [fptmp]            ; save FPU status word
    mov      ax, [fptmp]        ; check FPU status word
    cmp      al, 0              ; was correct status written?
    xor      bx, bx             ; no FPU present
    jne      GetFpuEnd          ; end procedure
    fnstsw   [fptmp]            ; save FPU status word
    mov      ax, [fptmp]        ; check FPU status word


   The "cmp al,0" is undone by "xor bx,bx" and the next "jne"
is never taken.  And "fnstsw fptmp" is duplicated.  But it all
looks harmless.

Regards,

Steve N.

[Gunther]

Greenhorn,

on page 3, last sentence:

correct. However, this is annoying. I don't remember how many times I read the text for proofreading; I missed the error. I changed that under the first post in the thread. The current archive with
the corrected PDF file is ESTIM1.ZIP.

Steve,

   The "cmp al,0" is undone by "xor bx,bx" and the next "jne"
is never taken.  And "fnstsw fptmp" is duplicated.  But it all
looks harmless.

your reasoning sounds conclusive. I'll take another close look at the code. I did follow Intel's recommendations, but things like this can still happen.

Many thanks to both of you.

[HSE]

Hi Gunther!!

There are problems with functions descriptions in estim.asm because arguments are pushed in reverse order.

Code (estim.asm ln 70) Select Expand

; CalcL2L3
; Purpose:   Calculate L2/L3.
; Input:     [bp+6]  = address L2   <---- is L3
;            [bp+10] = address L3   <---- is L2
; Output:    L2/L3   
CalcL2L3 proc far
    push     bp
    mov      bp, sp
    push     ds
    push     es
    push     di
    push     si
    lds      si, [bp+6]         ; ds:si -> L2   <---- is L3
    les      di, [bp+10]        ; es:di -> L3   <---- is L2


Not problem for calculations because storage in FPU registers is correct:

Code (Estim.asm ln 85) Select Expand


    fld      tbyte ptr es:[di]  ; st(0) = L2
    fld      tbyte ptr ds:[si]  ; st(0) = L3


Same thing happen in CalcExpE, CalcExpD, CalcExpC, CalcExpB and CalcExpA.

Very nice graphic 

Regards, HSE.

[Gunther]

HSE,

There are problems with functions descriptions in estim.asm because arguments are pushed in reverse order.

right, I'll correct that in the comments as soon as I've time. Probably along with the note by Steve.

Very nice graphic 

Well, I've made an effort. If you mean figure 1, it's only a sketch to illustrate a mathematical fact. But behind many complicated-sounding mathematical definitions and theorems often exist
very plausible geometric facts. That's what I'm trying to show. The language of modern mathematics is geometry.

[Gunther]

An important correction is also needed here.

Once I added the corrected function GetFpu to the assembly language source. This was pointed out to me by FORTRANS.
I've already written everything necessary for this here.

HSE further informed me of errors in the comments and procedure descriptions. I have also changed this in the ESTIM.ASM file.
The right archive with the corrected file is ESTIM2.ZIP and is below the first post of this thread.

My thanks goes to HSE as well.