DOS printf sources.

[caiiiycuk]

Hello, I am the author of the js-dos project. I use watcom to complie DOS benchmark program (dhry2). I am experiencing a very strange problem with dosbox-x compiled to emscripten. I am using this very simple program:

#include <conio.h>

void main (int argc, char *argv[]) {
  printf("%.2f\n", (double) 1000);
}

I compile it for dos, and run it with dosbox-x in browser and PC. The PC output is 1000.00, but the browser output is 0.00.
The weirdest thing is that this only happens with printf and %.2f, for example, I tried David M. Gay's 'dtoa()' function to print the doubles
manually and it works exactly the same under dosbox-x in browser and PC.

So I think the openwatcom implementation has something that is emulating incorrectly in the browser under dosbox-x. I have tried to find sources but no luck. Can you tell me where to find them. At least what algorithm is used to parse %.2f.

[jmalak]

You compile and link it as 16-bit or 32-bit DOS application?
What host OS you are using for build this application?

[caiiiycuk]

I use Ubuntu to build app

[jmalak]

add -fm option to wcl command line; it creates linker map file.
please put it here for analysis, it could be some mixture of incorrect libraries for linking.

[jmalak]

I checked it with your exact command line and it cannot compile due to errors.
Try this one
wcl -bt=dos -ldos -otexan -fm -ms -wx main.cpp
there is problem that it is compiled as C++ source and also printf is unprototyped (you need stdio.h header file instead of conio.h) that it uses by default int arguments. below is corrected source file

#include <stdio.h>

int main () {
  printf("%.2f\n", (double) 1000);
  return(0);
}

probably -I"$WATCOM/h" is source of problem it is not expanded and therefore it uses linux version of headers which uses different alignment then DOS header files. Take into acount that you cross-compile and OW is configured by default for target same as host system. cross-compilation is mainly about header files location that you can define it by INCLUDE environment variable. For DOS target it should be INCLUDE=<OW location>/h anotzher possibility is to define environment variable DOS_INCLUDE=<OW location>/h then it will be used only for DOS target (-bt=dos).

[caiiiycuk]

Ahh, ok, I used openwatcom 1.9 to build this example. Anyway I switched to v2, and changed sources, now my build script is:

#!/bin/bash

set -ex

rm -f *.o *.exe
source ~/sdk/ow2/owsetenv.sh
DOS_INCLUDE=$WATCOM/h wcl -bt=dos -ldos -otexan -fm -ms -wx main.cpp
rm -f *.o

The results are the same. Just to clarify, I don't think there is a bug in OpenWatcom or that my program is messed up. I believe something is wrong inside DosBox-X because the compiled program works fine in DosBox PC, DosBox Browser, and DosBox-X PC; it only prints wrong results in DosBox-X Browser.

My plan is to write a minimal test case that replicates the functionality of printf and debug it.

Here is map file:
main.map.txt

[jmalak]

Thanks for map file, it confirm that linking is OK, linker use correct libraries.
Anyway what describe is strange behaviour.
Try to look into compiled main.o file for path to stdio.h, there should be full path that it confirms if you have proper include path.
It should be <OW location>/h/stdio.h if it has <OW location>/lh/stdio.h then you use Linux header files and it is reason for issue.

I am not sure if it is copy-paste error, but your script should be

#!/bin/bash

set -ex

rm -f *.o *.exe
source ~/sdk/ow2/owsetenv.sh
DOS_INCLUDE=$WATCOM/h
wcl -bt=dos -ldos -otexan -fm -ms -wx main.cpp
rm -f *.o

[caiiiycuk]

I am trying to extract ldcvt from open-watcom-v2 source and compile it for dos. I almost done with this, but I have only one problem, with this assembler pragma:

#pragma aux   __LDI4 = \
                    "push  bp" \
                    "mov   bp,ax" \
        float_fixup "fld   tbyte ptr [bp]" \
                    "push  dx" \
                    "push  ax" \
                    "push  ax" \
                    "mov   bp,sp" \
        float_fixup "fstcw [bp]" \
        float_fixup "fwait" \
                    "pop   ax" \
                    "push  ax" \
                    "or    ah,0x0c" \
                    "mov   2[bp],ax" \
        float_fixup "fldcw 2[bp]" \
        float_fixup "fistp dword ptr 2[bp]" \
        float_fixup "fldcw [bp]" \
                    "pop   ax" \
                    "pop   ax" \
                    "pop   dx" \
                    "pop   bp" \
        __parm __caller [__ax] \
        __value [__dx __ax]

When I try to compile it with command

DOS_INCLUDE=$WATCOM/h wcl -bt=dos -ldos -otexan -fm -ms -wx ldcvt.c

I have following error:

ldcvt.c: 977 lines, included 1473, 0 warnings, 0 errors
ldcvt.c(977): Error! E1121: Procedure '__LDI4' has invalid return register in #pragma
ldcvt.c(977): Error! E1121: Procedure '__LDI4' has invalid return register in #pragma
Code size: 2981
Error: Compiler returned a bad status compiling 'ldcvt.c'

All other pragmas are ok. Can I fix it somehow?

[caiiiycuk]

Here it is
ldcvt.c.txt

[jmalak]

You have mistake in i4 prototype.
typedef int i4;
correct is
typedef long i4;
It caused a problem that pragma aux has return value 32-bit but C declaration has 16-bit, that dx:ax was incorrect for 16-bit return value which expect ax register only.
be careful about consistency between C prototype declaration and pragma aux declaration for bit-size of parameters and return value. Pragma aux is low-level description for code generator that diagnostics is minimal.

[caiiiycuk]

Fantastic, that works! As you said, I included xfloat.h, and it works out of the box. Can you show me how to write 1000.0 and 1000.0001 as a long double? It's tricky, if i use random values the outpus is always '0.', or infinite loop. I only found this which gives me very big non zero value.

    pld.low_word = 1848553472;
    pld.high_word = 4194304419;
    pld.exponent = 0x7FF0;

complete program
ldcvt.zip

Anyway, even with this big number, I can reproduce the problem. When I run this program in DOSBox-X on a PC, I get a big number in the output, but on DOSBox-X JSDOS, it shows zero. So, I have a good test program, but I want to be precise and test with 1000.00.

Thanks a lot!!!

[jmalak]

You can use OW X86 assembler WASM to create 10-bytes long double value
below is assembly source sample

.model small

.data

L1  dt  1000.0001

end

compile it by wasm with name of file only, no options are necessary.
next you can dissassembly it by wdis and you get binary value of this long double in readable form.

that for sample code you get

.387
DGROUP          GROUP   _DATA
_TEXT           SEGMENT WORD PUBLIC USE16 'CODE'
_TEXT           ENDS
_DATA           SEGMENT WORD PUBLIC USE16 'DATA'
    DB  0c4H, 0b1H, 2eH, 6eH, 0a3H, 1, 0, 0faH
    DB  8, 40H

_DATA           ENDS
                END

1000.0001 is in hex 0x4008fa0001a36e2eb1c4 (10-bytes)

[caiiiycuk]

Wow, that's so cool. Just for the record, 1000.0001 will be

    pld.high_word = 0xfa0001a3;
    pld.low_word  = 0x6e2eb1c4;
    pld.exponent  =     0x4008;

I hope the bug in DOSBox-X JS will be fixed soon. I will keep you posted.