OpenEuphoria

Re: bug in SOMETHING?!

• Posted by rforno at tutopia.com Feb 11, 2002
• 504 views

For your information, I discovered years ago a near-bug in the 486. Some
programs (an old version of APL, an Italian file compression program whose
name I don't remember at this very moment, and an old version of PCGLOBE)
ran OK on a 286, but failed on a 486. (The 386 had a similar problem, but it
didn't show in these programs). The reason is as follows: the programs
contained instructions that modified other instructions ahead. But in the
486, the modified instructions were already cached in the processor, and
then ran in unmodified state. This bug was removed in the Pentium. The
following is a small Assembler program that gives a correct result in a
Pentium and a wrong one in a 486. You may test several alternatives by
adding or removing 'and ax,ax' instructions between the modifying and the
modified instructions. I assembled the program with Borland Turbo Assembler
version 2.0.

        .MODEL  small
        .STACK  100h
        .DATA
Message DB      'Result is '
Result1 DB      ?
Result2 DB      ?
        DB      '; should be 05'
        DB      13,10,'$'
        .CODE
Start:
        mov     ax,@data
        mov     ds,ax
        mov     bh,0
        mov     cs:BYTE PTR modif+1,5
        and     ax,ax
        and     ax,ax
modif:
        mov     bl,0
        add     bl,'0'
        add     bh,'0'
        mov     Result1,bh
        mov     Result2,bl
        mov     dx,OFFSET Message
        mov     ah,9
        int     21h
        mov     ah,4ch
        int     21h
        END     Start



----- Original Message -----
From: <tubby.toast at ntlworld.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 11, 2002 5:01 PM
Subject: bug in SOMETHING?!


>
> I have code a bit like this
>
> a=allocate_string("blah")
> err=c_func(functionname,{a})  --err<0 on error, 0 on success
> free(a)
>
> The code works fine on my Celeron/433 running Windows 98, whatever I do.
It
> works fine on my Windows 95 486-SX/50 too - unless I bind it with
shrouding
> enabled.  err then shows an error.  However, if I then comment out the
> free(a) line, err shows success.
>
> Now why should this be?  Euphoria seems to be executing the third line
> before the second in some circumstances.
>
> So I forced the program to check that functionname had been executed by
> checking for the value of err before freeing a:
>
> a=allocate_string("blah")
> err=c_func(functionname,{a})
> if err then end if  --check value of err
> free(a)
>
> and everything works fine.  But this has taken days to track down.
>
> So is this a bug in
> a) my code
> b) Euphoria
> c) Windows 95
> d) the 486 chip
> e) something else?
>
> chrissy.
>
>
>
>