WASM changes

33 views
Skip to first unread message

Bartosz Polednia

unread,
Dec 2, 2006, 7:16:50 AM12/2/06
to
Hi,

As there was no direct objections about Paul proposed changes I have
submitted them into Perforce.


Bartosz.

Paul Edwards

unread,
Dec 2, 2006, 12:21:10 PM12/2/06
to
"Bartosz Polednia" <bart...@op.pl> wrote in message news:ekrqqg$k5n$1...@www-1.scitechsoft.com...

> As there was no direct objections about Paul proposed changes I have
> submitted them into Perforce.

Thanks Bartosz. I'll wait for the daily snapshot and verify that
all the changes are in.

BFN. Paul.


Michal Necasek

unread,
Dec 3, 2006, 9:41:18 AM12/3/06
to
Excellent - I see you have volunteered to be the new wasm maintainer.
And you know wasm well enough that you don't need any of those boring
regression tests I was asking for.

No doubt you will swiftly resolve the problem that Peter reported. FYI
the problem is this: assembling a file containing only '.model small'
with -ms produces several "Label is already defined" errors.


Michal

Bartosz Polednia

unread,
Dec 3, 2006, 2:46:39 PM12/3/06
to
Next lesson taken. DO NOT HELP.

I have been waiting 3 days for bug reports.

Paul, you need to find someone else to make submits.

Bartosz.

Mat Nieuwenhoven

unread,
Dec 3, 2006, 3:01:27 PM12/3/06
to
On Sun, 03 Dec 2006 20:46:39 +0100, Bartosz Polednia wrote:

>Next lesson taken. DO NOT HELP.
>
>I have been waiting 3 days for bug reports.

You mean you put something in without checking it first yourself? What was
stopping you from doing a full clean/build with Paul's patches?

Mat Nieuwenhoven

Bartosz Polednia

unread,
Dec 3, 2006, 4:15:51 PM12/3/06
to
Frankly writing: nothing.

I do not say that I am innocent.

Bartosz.

Paul Edwards

unread,
Dec 3, 2006, 4:45:43 PM12/3/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:ekunlg$rrn$1...@www-1.scitechsoft.com...

> Bartosz Polednia wrote:
> > Hi,
> >
> > As there was no direct objections about Paul proposed changes I have
> > submitted them into Perforce.
> >
> Excellent - I see you have volunteered to be the new wasm maintainer.

It's a team effort.

> And you know wasm well enough that you don't need any of those boring
> regression tests I was asking for.

The tests were already failing, as you noted.

> No doubt you will swiftly resolve the problem that Peter reported. FYI
> the problem is this: assembling a file containing only '.model small'
> with -ms produces several "Label is already defined" errors.

Thanks for simplifying the problem. I think I know what the
problem is, let me resolve it.

BFN. Paul.


Paul Edwards

unread,
Dec 3, 2006, 4:55:01 PM12/3/06
to
"Bartosz Polednia" <bart...@op.pl> wrote in message news:ekv9hs$32e$1...@www-1.scitechsoft.com...

> Next lesson taken. DO NOT HELP.

It's a minor problem. WASM is now significantly more usable.

> Paul, you need to find someone else to make submits.

This should be the last one.

BFN. Paul.


Index: direct.c
===================================================================
RCS file: j:\cvsroot/ow/bld/wasm/c/direct.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -c -r1.9 -r1.10
*** direct.c 3 Dec 2006 21:04:44 -0000 1.9
--- direct.c 3 Dec 2006 21:52:48 -0000 1.10
***************
*** 2075,2080 ****
--- 2075,2085 ----
TypeInfo[TOK_EXT_PTR].value = MT_DWORD;
break;
}
+ /* If the equates have already been defined, don't redefine them */
+ if (ModuleInfo.init == TRUE)
+ {
+ return;
+ }
/* Set @CodeSize equate */
switch( type ) {
case MOD_MEDIUM:


Bartosz Polednia

unread,
Dec 4, 2006, 2:40:59 AM12/4/06
to
Paul Edwards napisał(a):

> "Bartosz Polednia" <bart...@op.pl> wrote in message news:ekv9hs$32e$1...@www-1.scitechsoft.com...
>> Next lesson taken. DO NOT HELP.
>
> It's a minor problem.

It is a MAJOR problem.

I could submit code once more if and only if:

1. you prepare new regression tests,
2. you prepare results of all regression tests,
3. you verify that new & old tests give same results even if they fail,
3. I will receive acceptance from other submitters.

Bartosz.

Michal Necasek

unread,
Dec 4, 2006, 6:26:14 AM12/4/06
to
Paul Edwards wrote:

>> And you know wasm well enough that you don't need any of those boring
>> regression tests I was asking for.
>
> The tests were already failing, as you noted.
>

Yes, but the build wasn't, and the wasm test failures were unrelated
to the changes you suggested.

>> No doubt you will swiftly resolve the problem that Peter reported. FYI
>> the problem is this: assembling a file containing only '.model small'
>> with -ms produces several "Label is already defined" errors.
>
> Thanks for simplifying the problem. I think I know what the
> problem is, let me resolve it.
>

My post - in case there was some uncertainty - was not aimed at you.
You designed fixes that you needed, but it is the responsibility of the
person checking in a change to make sure that the change is correct and
will not cause any build breaks (plus hopefully won't break other
people's code either).

In this particular case, the problem was not clear-cut at all, there
was a conflict between the -mxxx switch and the .model directive. I'm
not surprised that you hadn't anticipated the conflict. But it is the
job of the person checking in changes to expect the unexpected.

Also, because wasm is always freshly built at the start of a full
build, any problems with wasm will cause build breaks rather quickly. I
do not expect you to know that, but I expect the person checking in
changes to wasm to know that, and act accordingly.

Thanks for the wasm updates BTW, the assembler definitely needs it.
The text parsing and some of the semantics are wrong (ie. not like
MASM). Anything that brings wasm closer to MASM is a good thing.


Michal

Paul Edwards

unread,
Dec 4, 2006, 6:58:34 AM12/4/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:el10jp$ihq$1...@www-1.scitechsoft.com...

> Paul Edwards wrote:
>
> >> And you know wasm well enough that you don't need any of those boring
> >> regression tests I was asking for.
> >
> > The tests were already failing, as you noted.
> >
> Yes, but the build wasn't, and the wasm test failures were unrelated
> to the changes you suggested.

Sure. I had noticed that someone said they were going to update
the testcases and make them get run as part of the build, so I was
waiting for that to happen so that I could make sure the .log file
was all "OK". I wasn't in a rush.

> >> No doubt you will swiftly resolve the problem that Peter reported. FYI
> >> the problem is this: assembling a file containing only '.model small'
> >> with -ms produces several "Label is already defined" errors.
> >
> > Thanks for simplifying the problem. I think I know what the
> > problem is, let me resolve it.
> >
> My post - in case there was some uncertainty - was not aimed at you.
> You designed fixes that you needed, but it is the responsibility of the
> person checking in a change to make sure that the change is correct and
> will not cause any build breaks (plus hopefully won't break other
> people's code either).

Understood, but I feel guilty anyway. :-)

> In this particular case, the problem was not clear-cut at all, there
> was a conflict between the -mxxx switch and the .model directive. I'm
> not surprised that you hadn't anticipated the conflict. But it is the
> job of the person checking in changes to expect the unexpected.

Well, I was hoping someone would do the build anyway,
as I don't appear to have the ability to do that. I can build
wasm, but there are many errors in the rest of the build on
my system, at least appearing on my screen. I haven't
investigated any log files.

> Also, because wasm is always freshly built at the start of a full
> build, any problems with wasm will cause build breaks rather quickly. I
> do not expect you to know that, but I expect the person checking in
> changes to wasm to know that, and act accordingly.

Ok.

> Thanks for the wasm updates BTW, the assembler definitely needs it.
> The text parsing and some of the semantics are wrong (ie. not like
> MASM). Anything that brings wasm closer to MASM is a good thing.

No problem. I just hope I can get it in 1.6 so that I don't need to
maintain separate source code.

BFN. Paul.


Michal Necasek

unread,
Dec 4, 2006, 10:54:46 AM12/4/06
to
Paul Edwards wrote:

> Well, I was hoping someone would do the build anyway,
> as I don't appear to have the ability to do that. I can build
> wasm, but there are many errors in the rest of the build on
> my system, at least appearing on my screen. I haven't
> investigated any log files.
>

That has probably something to do with you running Win98... if you can
figure out why the behaviour on Win9x is less than useful, we can fix
that. It's just that most people (myself included) don't even have a
Win9x setup around anymore.

> No problem. I just hope I can get it in 1.6 so that I don't need to
> maintain separate source code.
>

I'm sure that would be preferable for everyone involved...


Michal

Mat Nieuwenhoven

unread,
Dec 4, 2006, 12:30:24 PM12/4/06
to
On Mon, 04 Dec 2006 08:40:59 +0100, Bartosz Polednia wrote:

>Paul Edwards napisa (a):

It would help already if Paul himself did a full clean/build before he
published his patches.

Mat Nieuwenhoven


Paul Edwards

unread,
Dec 4, 2006, 4:05:14 PM12/4/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:el1gba$qjq$1...@www-1.scitechsoft.com...

> Paul Edwards wrote:
>
> > Well, I was hoping someone would do the build anyway,
> > as I don't appear to have the ability to do that. I can build
> > wasm, but there are many errors in the rest of the build on
> > my system, at least appearing on my screen. I haven't
> > investigated any log files.
> >
> That has probably something to do with you running Win98... if you can
> figure out why the behaviour on Win9x is less than useful, we can fix
> that. It's just that most people (myself included) don't even have a
> Win9x setup around anymore.

Ok, I've found a build.log, and this is the first error I have:

================ 19:40:32 j:\devel\ow\bld\sdk\rc\rc\prebuild ================
wrc -q -bt=windows -Ij:\devel\ow\bld\watcom\h -zk0 -r -ad -I../h ..\rc.rc -fo=wrc.res
usage.rc(1): Fatal Error! 55: Unknown preprocessor directive
Error(E14): Cannot execute (wrc): No error
Error(E42): Last command making (wrc.res) returned a bad status
Error(E02): Make execution terminated
Can not open 'j:\devel\ow\bld\sdk\rc\rc\prebuild\wrce.exe' for reading: No such file or directory
<acopy wrce.exe j:\devel\ow\bld\build\binnt/bwrc.exe> => non-zero return: 1

Given that I'm using version 1.5 of OW, I am surprised that I have this
error, as wrc is coming from there. Anyway, here is the first line of
usage.rc:

#-1), "Usage: %s {options} input-filename {options} [output-filename] {options}"

Any ideas?

BFN. Paul.


Paul Edwards

unread,
Dec 4, 2006, 4:07:55 PM12/4/06
to
"Mat Nieuwenhoven" <mni...@dontincludethis.zap.a2000.nl> wrote in message
news:zavrhjqbagvapyhqrguvf...@news.openwatcom.org...

> It would help already if Paul himself did a full clean/build before he
> published his patches.

I had already attempted to do that, but I got a lot of errors, but
I didn't investigate further as I assumed the build process
required something I didn't have. Since wasm was compiling
fine I was able to test my changes.

BFN. Paul.


Michal Necasek

unread,
Dec 4, 2006, 4:46:06 PM12/4/06
to
Paul Edwards wrote:
> Ok, I've found a build.log, and this is the first error I have:
>
> ================ 19:40:32 j:\devel\ow\bld\sdk\rc\rc\prebuild ================
> wrc -q -bt=windows -Ij:\devel\ow\bld\watcom\h -zk0 -r -ad -I../h ..\rc.rc -fo=wrc.res
> usage.rc(1): Fatal Error! 55: Unknown preprocessor directive
>
The file usage.rc is autogenerated. The first line is supposed to look
like this:

(MSG_USE_E_BASE+1-1), "Usage: %s {options} input-filename {options}
[output-filename] {options}"

I suspect there are problems caused either by brain damaged
command.com command line parsing or possibly command line limitations.
The error you're seeing isn't caused by wrc at all, it's caused by
incorrectly generated source file.


Michal

Hans-Bernhard Bröker

unread,
Dec 4, 2006, 5:03:36 PM12/4/06
to
Michal Necasek wrote:

> I suspect there are problems caused either by brain damaged command.com
> command line parsing or possibly command line limitations. The error
> you're seeing isn't caused by wrc at all, it's caused by incorrectly
> generated source file.

Suspicion seconded. The wsplice command line that build wrc.res
contains some pretty fearsome quoting (for a Windows command shell, that
is). It's certainly fragile enough for the difference between
command.com (Win9x) and cmd.exe (NT family) to break it. Command.com's
treatment of tightly packed sequences of backslashes and double-quotes
is FUBAR.

japheth

unread,
Dec 4, 2006, 5:05:28 PM12/4/06
to
> I suspect there are problems caused either by brain damaged command.com
> command line parsing or possibly command line limitations. The error
> you're seeing isn't caused by wrc at all, it's caused by incorrectly
> generated source file.

I remember there once was a problem with 0x0A line ends missing the 0x0D. Has
this issue been solved now?

Paul Edwards

unread,
Dec 4, 2006, 5:24:07 PM12/4/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:el24u2$2kb$1...@www-1.scitechsoft.com...

Ok, I checked out a fresh build and tried again, just trying to build in
the sdk\rc\rc directory to see if I could isolate the error. After a bit
of stuffing around, I now have a new "first error".

============== 09:13:58 J:\devel\ow\bld\sdk\rc\wres\dosi86\mc ===============
cc loadstr.obj
...
cc wrmergdi.obj
%create wres.lbc
bwlib -q -zld -b-n -s-t -p=16 wres.lib @wres.lbc
Error(E14): Cannot execute (bwlib): No such file or directory
Error(E42): Last command making (wres.lib) returned a bad status
Error(E02): Make execution terminated
============== 09:14:03 J:\devel\ow\bld\sdk\rc\wres\dosi86\mh ===============

I don't have a "bwlib", but I don't know which makefile this is
coming from so that I can find out if bwlib is an error in itself.

Any idea?

BFN. Paul.


Hans-Bernhard Bröker

unread,
Dec 4, 2006, 6:01:11 PM12/4/06
to Paul Edwards
Paul Edwards wrote:

> Ok, I checked out a fresh build and tried again, just trying to build in
> the sdk\rc\rc directory to see if I could isolate the error. After a bit
> of stuffing around, I now have a new "first error".

Not really. This is not really a first error, it's just the first after
some random point at which you jumped into the middle of the full
'builder build' process.

> I don't have a "bwlib", but I don't know which makefile this is
> coming from so that I can find out if bwlib is an error in itself.

bwlib is the freshly built version of wlib.

I recommend you don't try to second-guess 'builder'. It knows what to
do in which order better than you do at this point.

Paul Edwards

unread,
Dec 4, 2006, 6:05:17 PM12/4/06
to
"Hans-Bernhard Bröker" <bro...@physik.rwth-aachen.de> wrote in message news:4574A8B7...@physik.rwth-aachen.de...

> Paul Edwards wrote:
>
> > Ok, I checked out a fresh build and tried again, just trying to build in
> > the sdk\rc\rc directory to see if I could isolate the error. After a bit
> > of stuffing around, I now have a new "first error".
>
> Not really. This is not really a first error, it's just the first after
> some random point at which you jumped into the middle of the full
> 'builder build' process.

Ok, my experience with wasm was that I didn't need to build
the whole world, and that it would recompile the needed stuff
on its own.

> > I don't have a "bwlib", but I don't know which makefile this is
> > coming from so that I can find out if bwlib is an error in itself.
>
> bwlib is the freshly built version of wlib.

Ok.

> I recommend you don't try to second-guess 'builder'. It knows what to
> do in which order better than you do at this point.

I wasn't trying to second-guess it, I was just trying to build the
bit that was failing, so that I could try to find out why it wasn't
working on Win98.

BFN. Paul.


Paul Edwards

unread,
Dec 4, 2006, 6:10:48 PM12/4/06
to
Ok, here are the code changes, plus build fix, plus new regression
test, plus new regression tests results. These code changes are all
against the latest (2006-12-04) source.

I have run all the wasm regression tests, and only one of them had
a difference, and that difference (adding DATA to tiny) was expected,
and I have updated the test results to reflect that.

I am unable to run the wcc regression test cases because I am
unable to build wcc. I am unable to test that the build works,
because I am unable to build the build. Can someone help me
out in doing both of these tasks? I would very much like to get
these changes into 1.6 so that I don't need to maintain separate
source code.

Thanks. Paul.


Index: ow/bld/builder/master.mif
diff -c ow/bld/builder/master.mif:1.1.1.1 ow/bld/builder/master.mif:1.2
*** ow/bld/builder/master.mif:1.1.1.1 Wed Nov 29 12:58:38 2006
--- ow/bld/builder/master.mif Wed Nov 29 13:39:00 2006
***************
*** 47,53 ****
$(cl) $(clflags) $<
!ifndef __$(host_os)__ # Don't copy unless host_os=build_os
!else ifndef __UNIX__ # Avoid "text file busy".
! copy $^. $(%OWBINDIR)\ > nul # MS-influenced command noisy
!endif
!endif

--- 47,53 ----
$(cl) $(clflags) $<
!ifndef __$(host_os)__ # Don't copy unless host_os=build_os
!else ifndef __UNIX__ # Avoid "text file busy".
! copy $^. $(%OWBINDIR) > nul # MS-influenced command noisy
!endif
!endif

***************
*** 57,63 ****
!else ifdef __UNIX__
cp $^. $(%OWBINDIR)/$^& # Remove .exe from working name
!else
! copy $^. $(%OWBINDIR)\ > nul # MS-influenced command noisy
!endif

# runasdos will run itself under dosemu. Copy once for each program that still
--- 57,63 ----
!else ifdef __UNIX__
cp $^. $(%OWBINDIR)/$^& # Remove .exe from working name
!else
! copy $^. $(%OWBINDIR) > nul # MS-influenced command noisy
!endif

# runasdos will run itself under dosemu. Copy once for each program that still
Index: ow/bld/wasm/c/asmline.c
diff -c ow/bld/wasm/c/asmline.c:1.1.1.3 ow/bld/wasm/c/asmline.c:1.7
*** ow/bld/wasm/c/asmline.c:1.1.1.3 Mon Dec 04 19:31:00 2006
--- ow/bld/wasm/c/asmline.c Mon Dec 04 20:22:44 2006
***************
*** 151,157 ****
skip = TRUE;
break;
case '\n':
- #if 0
/* Paul Edwards */
/* if continuation character found, pass over newline */
if( (got_something == TRUE) && (*(ptr - 1) == '\\') ) {
--- 151,156 ----
***************
*** 160,166 ****
LineNumber++;
continue; /* don't store character in string */
}
- #endif
*ptr = '\0';
// fall through
case '\0':
--- 159,164 ----
Index: ow/bld/wasm/c/asmscan.c
diff -c ow/bld/wasm/c/asmscan.c:1.1.1.1 ow/bld/wasm/c/asmscan.c:1.3
*** ow/bld/wasm/c/asmscan.c:1.1.1.1 Wed Nov 29 12:59:14 2006
--- ow/bld/wasm/c/asmscan.c Tue Dec 05 06:21:02 2006
***************
*** 614,620 ****
CurrString = string;
output_ptr = stringbuf;

! for( ptr = string; ; ) {
AsmBuffer[buf_index]->string_ptr = output_ptr;

while( isspace( *ptr ) ) {
--- 614,626 ----
CurrString = string;
output_ptr = stringbuf;

! ptr = string;
! /* skip initial spaces and expansion codes */
! while( isspace( *ptr ) || (*ptr == '%') ) {
! ptr++;
! }
!
! for( ; ; ) {
AsmBuffer[buf_index]->string_ptr = output_ptr;

while( isspace( *ptr ) ) {
Index: ow/bld/wasm/c/direct.c
diff -c ow/bld/wasm/c/direct.c:1.1.1.3 ow/bld/wasm/c/direct.c:1.13
*** ow/bld/wasm/c/direct.c:1.1.1.3 Mon Dec 04 19:31:00 2006
--- ow/bld/wasm/c/direct.c Mon Dec 04 20:25:38 2006
***************
*** 2043,2049 ****
InputQueueLine( get_sim_code_end( buffer, Options.text_seg ) );

/* Generates codes for data segment */
! if( type != MOD_TINY ) {
InputQueueLine( SimCodeBegin[bit][SIM_DATA] );
InputQueueLine( SimCodeEnd[SIM_DATA] );
}
--- 2043,2049 ----
InputQueueLine( get_sim_code_end( buffer, Options.text_seg ) );

/* Generates codes for data segment */
! if( 1 ) { /* type != MOD_TINY */
InputQueueLine( SimCodeBegin[bit][SIM_DATA] );
InputQueueLine( SimCodeEnd[SIM_DATA] );
}
***************
*** 2053,2060 ****
switch( type ) {
case MOD_TINY:
strcat( buffer, Options.text_seg );
! InputQueueLine( buffer );
! break;
case MOD_SMALL:
case MOD_COMPACT:
case MOD_MEDIUM:
--- 2053,2060 ----
switch( type ) {
case MOD_TINY:
strcat( buffer, Options.text_seg );
! strcat( buffer, ", ");
! /* fall through */
case MOD_SMALL:
case MOD_COMPACT:
case MOD_MEDIUM:
***************
*** 2066,2073 ****
}
ModelAssumeInit();

- #if 0
/* Paul Edwards */
{
int modelnum = -1;
/* Fix up PTR size */
--- 2066,2073 ----
}
ModelAssumeInit();

/* Paul Edwards */
+ if (ModuleInfo.init == FALSE)
{
int modelnum = -1;
/* Fix up PTR size */
***************
*** 2136,2142 ****
InputQueueLine( buffer );
}
}
- #endif
}

void ModuleInit( void )
--- 2136,2141 ----
***************
*** 2753,2759 ****
case TOK_PROC_VARARG:
return( 0 );
default:
- #if 0
if ( type == TOK_EXT_PTR ) {
if( ( ModuleInfo.model == MOD_COMPACT )
|| ( ModuleInfo.model == MOD_LARGE )
--- 2752,2757 ----
***************
*** 2762,2768 ****
}
else return ( 2 );
}
- #endif
return( ERROR );
}
}
--- 2760,2765 ----
Index: ow/bld/wasm/h/directd.h
diff -c ow/bld/wasm/h/directd.h:1.1.1.3 ow/bld/wasm/h/directd.h:1.4
*** ow/bld/wasm/h/directd.h:1.1.1.3 Mon Dec 04 19:30:42 2006
--- ow/bld/wasm/h/directd.h Mon Dec 04 20:22:10 2006
***************
*** 62,71 ****
fix( TOK_EXT_SBYTE, "SBYTE", MT_BYTE, 0 ),
fix( TOK_EXT_WORD, "WORD", MT_WORD, 0 ),
fix( TOK_EXT_SWORD, "SWORD", MT_WORD, 0 ),
- #if 0
- /* Paul Edwards */
fix( TOK_EXT_PTR, "PTR", MT_WORD, 0 ),
- #endif
fix( TOK_EXT_DWORD, "DWORD", MT_DWORD, 0 ),
fix( TOK_EXT_SDWORD, "SDWORD", MT_DWORD, 0 ),
fix( TOK_EXT_PWORD, "PWORD", MT_FWORD, 0 ),
--- 62,68 ----
Index: ow/bld/wasm/test/test1/beep.esm
diff -c ow/bld/wasm/test/test1/beep.esm:1.1.1.1 ow/bld/wasm/test/test1/beep.esm:1.2
*** ow/bld/wasm/test/test1/beep.esm:1.1.1.1 Wed Nov 29 12:59:12 2006
--- ow/bld/wasm/test/test1/beep.esm Tue Dec 05 06:26:30 2006
***************
*** 1,13 ****
.387
! DGROUP GROUP _TEXT
_TEXT SEGMENT WORD PUBLIC USE16 'CODE'
ASSUME CS:DGROUP, DS:DGROUP, SS:DGROUP
! mov ah,2
! mov dl,7
! int 21H
! mov ah,2
! mov dl,7
! int 21H
! ret
_TEXT ENDS
END
--- 1,15 ----
.387
! DGROUP GROUP _TEXT,_DATA
_TEXT SEGMENT WORD PUBLIC USE16 'CODE'
ASSUME CS:DGROUP, DS:DGROUP, SS:DGROUP
! mov ah,2
! mov dl,7
! int 21H
! mov ah,2
! mov dl,7
! int 21H
! ret
_TEXT ENDS
+ _DATA SEGMENT WORD PUBLIC USE16 'DATA'
+ _DATA ENDS
END
Index: ow/bld/wasm/test/test3/makefile
diff -c ow/bld/wasm/test/test3/makefile:1.1.1.1 ow/bld/wasm/test/test3/makefile:1.2
*** ow/bld/wasm/test/test3/makefile:1.1.1.1 Wed Nov 29 12:59:12 2006
--- ow/bld/wasm/test/test3/makefile Tue Dec 05 06:47:54 2006
***************
*** 44,49 ****
--- 44,50 ----
sse3 &
struct1 &
structdd &
+ support &
tbyte &
testequ &
tst1
***************
*** 57,61 ****
--- 58,63 ----
asm_flags_callcnv5 = -zcm
asm_flags_jmpshrt = -zcm
asm_flags_retiret = -zcm
+ asm_flags_support = -zcm -Dmemodel=large

!include ../test.mif
Index: ow/bld/wasm/test/test3/support.asm
diff -c /dev/null ow/bld/wasm/test/test3/support.asm:1.1
*** /dev/null Tue Dec 05 08:58:58 2006
--- ow/bld/wasm/test/test3/support.asm Tue Dec 05 06:51:08 2006
***************
*** 0 ****
--- 1,240 ----
+ ; support.asm - assembler support functions for DOS
+ ;
+ ; This program written by Paul Edwards
+ ; Released to the public domain
+
+ % .model memodel, c
+
+ assume cs:_TEXT, ds:DGROUP
+
+ _DATA segment word public 'DATA'
+ _DATA ends
+ _BSS segment word public 'BSS'
+ _BSS ends
+
+ _TEXT segment word public 'CODE'
+
+ public int86
+ int86 proc uses ax bx cx dx si di ds es, \
+ intnum:word, regsin:ptr, regsout:ptr
+
+ if @DataSize
+ lds si, regsin
+ else
+ mov si, regsin
+ endif
+
+ mov ax, word ptr [si + 0]
+ mov bx, word ptr [si + 2]
+ mov cx, word ptr [si + 4]
+ mov dx, word ptr [si + 6]
+ mov di, word ptr [si + 10]
+ mov si, word ptr [si + 8]
+
+ push bp
+
+ cmp intnum, 08h
+ jne not8
+ int 08h
+ jmp fintry
+ not8:
+
+ cmp intnum, 09h
+ jne not9
+ int 09h
+ jmp fintry
+ not9:
+
+ cmp intnum, 010h
+ jne not10
+ int 010h
+ jmp fintry
+ not10:
+
+ cmp intnum, 013h
+ jne not13
+ int 013h
+ jmp fintry
+ not13:
+
+ cmp intnum, 015h
+ jne not15
+ clc ; interrupt doesn't set it it seems
+ int 015h
+ jmp fintry
+ not15:
+
+ cmp intnum, 016h
+ jne not16
+ int 016h
+ jmp fintry
+ not16:
+
+ cmp intnum, 020h
+ jne not20
+ int 020h
+ jmp fintry
+ not20:
+
+ cmp intnum, 021h
+ jne not21
+ int 021h
+ jmp fintry
+ not21:
+
+ fintry:
+
+ pop bp
+ push si
+
+ if @DataSize
+ lds si, regsout
+ else
+ mov si, regsout
+ endif
+
+ mov [si + 0], ax
+ mov [si + 2], bx
+ mov [si + 4], cx
+ mov [si + 6], dx
+ mov [si + 10], di
+ pop ax ; actually si
+ mov [si + 8], ax
+ mov word ptr [si + 12], 0
+ jnc flagclear
+ mov word ptr [si + 12], 1
+ flagclear:
+ pushf
+ pop ax
+ mov word ptr [si + 14], ax
+
+ ret
+ int86 endp
+
+
+
+ public int86x
+ int86x proc uses ax bx cx dx si di ds es, \
+ intnum:word, regsin:ptr, regsout:ptr, sregs:ptr
+
+ push ds; for restoration after interrupt
+
+ if @DataSize
+ lds si, sregs
+ else
+ mov si, sregs
+ endif
+
+ mov es, [si + 6]
+ push es ; new value for ds
+
+ mov es, [si + 0]
+
+ if @DataSize
+ lds si, regsin
+ else
+ mov si, regsin
+ endif
+
+ mov ax, word ptr [si + 0]
+ mov bx, word ptr [si + 2]
+ mov cx, word ptr [si + 4]
+ mov dx, word ptr [si + 6]
+ mov di, word ptr [si + 10]
+ mov si, word ptr [si + 8]
+
+ pop ds; load previously saved value for ds
+
+ cmp intnum, 08h
+ jne xnot8
+ int 08h
+ jmp xfintry
+ xnot8:
+
+ cmp intnum, 09h
+ jne xnot9
+ int 09h
+ jmp xfintry
+ xnot9:
+
+ cmp intnum, 010h
+ jne xnot10
+ int 010h
+ jmp xfintry
+ xnot10:
+
+ cmp intnum, 013h
+ jne xnot13
+ int 013h
+ jmp xfintry
+ xnot13:
+
+ cmp intnum, 015h
+ jne xnot15
+ clc ; interrupt doesn't set it it seems
+ int 015h
+ jmp xfintry
+ xnot15:
+
+ cmp intnum, 016h
+ jne xnot16
+ int 016h
+ jmp xfintry
+ xnot16:
+
+ cmp intnum, 021h
+ jne xnot21
+ int 021h
+ jmp xfintry
+ xnot21:
+
+ xfintry:
+
+ push es
+ push ds
+ push si
+ push ax
+ push bp
+
+ mov bp, sp
+ mov ax, [bp+10]; restore ds immediately, can't move without it
+ pop bp
+ mov ds, ax
+
+ if @DataSize
+ lds si, regsout
+ else
+ mov si, regsout
+ endif
+
+ pop ax
+ mov [si + 0], ax
+ mov [si + 2], bx
+ mov [si + 4], cx
+ mov [si + 6], dx
+ mov [si + 10], di
+ pop ax
+ mov [si + 8], ax ; si
+ mov word ptr [si + 12], 0
+ jnc xflagclear
+ mov word ptr [si + 12], 1
+ xflagclear:
+
+ if @DataSize
+ lds si, sregs
+ else
+ mov si, sregs
+ endif
+
+ pop ax
+ mov [si + 6], ax; restore ds
+ pop ax
+ mov [si + 0], ax ; restore es
+
+ pop ds ; restore value saved over interrupt (but accessed directly already)
+ ret
+ int86x endp
+
+ _TEXT ends
+
+ end
Index: ow/bld/wasm/test/test3/support.esm
diff -c /dev/null ow/bld/wasm/test/test3/support.esm:1.1
*** /dev/null Tue Dec 05 08:58:58 2006
--- ow/bld/wasm/test/test3/support.esm Tue Dec 05 06:46:00 2006
***************
*** 0 ****
--- 1,200 ----
+ .387
+ PUBLIC _int86
+ PUBLIC _int86x
+ DGROUP GROUP _DATA
+ support_TEXT SEGMENT WORD PUBLIC USE16 'CODE'
+ support_TEXT ENDS
+ _DATA SEGMENT WORD PUBLIC USE16 'DATA'
+ _DATA ENDS
+ _BSS SEGMENT WORD PUBLIC USE16 'BSS'
+ _BSS ENDS
+
+ _TEXT SEGMENT WORD PUBLIC USE16 'CODE'
+ ASSUME CS:_TEXT, DS:DGROUP, SS:DGROUP
+ _int86:
+ push bp
+ mov bp,sp
+ push ax
+ push bx
+ push cx
+ push dx
+ push si
+ push di
+ push ds
+ push es
+ lds si,dword ptr 8[bp]
+ mov ax,word ptr [si]
+ mov bx,word ptr 2[si]
+ mov cx,word ptr 4[si]
+ mov dx,word ptr 6[si]
+ mov di,word ptr 0aH[si]
+ mov si,word ptr 8[si]
+ push bp
+ cmp word ptr 6[bp],8
+ jne L$1
+ int 8
+ jmp L$8
+ L$1:
+ cmp word ptr 6[bp],9
+ jne L$2
+ int 9
+ jmp L$8
+ L$2:
+ cmp word ptr 6[bp],10H
+ jne L$3
+ int 10H
+ jmp L$8
+ L$3:
+ cmp word ptr 6[bp],13H
+ jne L$4
+ int 13H
+ jmp L$8
+ L$4:
+ cmp word ptr 6[bp],15H
+ jne L$5
+ clc
+ int 15H
+ jmp L$8
+ L$5:
+ cmp word ptr 6[bp],16H
+ jne L$6
+ int 16H
+ jmp L$8
+ L$6:
+ cmp word ptr 6[bp],20H
+ jne L$7
+ int 20H
+ jmp L$8
+ L$7:
+ cmp word ptr 6[bp],21H
+ jne L$8
+ int 21H
+ jmp L$8
+ L$8:
+ pop bp
+ push si
+ lds si,dword ptr 0cH[bp]
+ mov word ptr [si],ax
+ mov word ptr 2[si],bx
+ mov word ptr 4[si],cx
+ mov word ptr 6[si],dx
+ mov word ptr 0aH[si],di
+ pop ax
+ mov word ptr 8[si],ax
+ mov word ptr 0cH[si],0
+ jae L$9
+ mov word ptr 0cH[si],1
+ L$9:
+ pushf
+ pop ax
+ mov word ptr 0eH[si],ax
+ pop es
+ pop ds
+ pop di
+ pop si
+ pop dx
+ pop cx
+ pop bx
+ pop ax
+ pop bp
+ retf
+ _int86x:
+ push bp
+ mov bp,sp
+ push ax
+ push bx
+ push cx
+ push dx
+ push si
+ push di
+ push ds
+ push es
+ push ds
+ lds si,dword ptr 10H[bp]
+ mov es,word ptr 6[si]
+ push es
+ mov es,word ptr [si]
+ lds si,dword ptr 8[bp]
+ mov ax,word ptr [si]
+ mov bx,word ptr 2[si]
+ mov cx,word ptr 4[si]
+ mov dx,word ptr 6[si]
+ mov di,word ptr 0aH[si]
+ mov si,word ptr 8[si]
+ pop ds
+ cmp word ptr 6[bp],8
+ jne L$10
+ int 8
+ jmp L$16
+ L$10:
+ cmp word ptr 6[bp],9
+ jne L$11
+ int 9
+ jmp L$16
+ L$11:
+ cmp word ptr 6[bp],10H
+ jne L$12
+ int 10H
+ jmp L$16
+ L$12:
+ cmp word ptr 6[bp],13H
+ jne L$13
+ int 13H
+ jmp L$16
+ L$13:
+ cmp word ptr 6[bp],15H
+ jne L$14
+ clc
+ int 15H
+ jmp L$16
+ L$14:
+ cmp word ptr 6[bp],16H
+ jne L$15
+ int 16H
+ jmp L$16
+ L$15:
+ cmp word ptr 6[bp],21H
+ jne L$16
+ int 21H
+ jmp L$16
+ L$16:
+ push es
+ push ds
+ push si
+ push ax
+ push bp
+ mov bp,sp
+ mov ax,word ptr 0aH[bp]
+ pop bp
+ mov ds,ax
+ lds si,dword ptr 0cH[bp]
+ pop ax
+ mov word ptr [si],ax
+ mov word ptr 2[si],bx
+ mov word ptr 4[si],cx
+ mov word ptr 6[si],dx
+ mov word ptr 0aH[si],di
+ pop ax
+ mov word ptr 8[si],ax
+ mov word ptr 0cH[si],0
+ jae L$17
+ mov word ptr 0cH[si],1
+ L$17:
+ lds si,dword ptr 10H[bp]
+ pop ax
+ mov word ptr 6[si],ax
+ pop ax
+ mov word ptr [si],ax
+ pop ds
+ pop es
+ pop ds
+ pop di
+ pop si
+ pop dx
+ pop cx
+ pop bx
+ pop ax
+ pop bp
+ retf
+ _TEXT ENDS
+ END


Paul Edwards

unread,
Dec 4, 2006, 6:53:16 PM12/4/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:el24u2$2kb$1...@www-1.scitechsoft.com...

> Paul Edwards wrote:
> > Ok, I've found a build.log, and this is the first error I have:
> >
> > ================ 19:40:32 j:\devel\ow\bld\sdk\rc\rc\prebuild ================
> > wrc -q -bt=windows -Ij:\devel\ow\bld\watcom\h -zk0 -r -ad -I../h ..\rc.rc -fo=wrc.res
> > usage.rc(1): Fatal Error! 55: Unknown preprocessor directive
> >
> The file usage.rc is autogenerated. The first line is supposed to look
> like this:
>
> (MSG_USE_E_BASE+1-1), "Usage: %s {options} input-filename {options}
> [output-filename] {options}"

I copied the following line:
wsplice -kENGLISH -kIS_RC -knt -t8 -f "%+(MSG_USE_E_BASE+%#-1), \"%s\"" ../usage.sp usage.rc

into a batch file, then I changed the "%" to "%%" and ran it,
and got the same (ie correct) results you did.

Where is the makefile that has this command in it? I'll try
changing the makefile to include two % to see if that fixes
the problem.

BFN. Paul.


Paul Edwards

unread,
Dec 4, 2006, 8:20:52 PM12/4/06
to
"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message news:el2cje$5g2$1...@www-1.scitechsoft.com...

> I copied the following line:
> wsplice -kENGLISH -kIS_RC -knt -t8 -f "%+(MSG_USE_E_BASE+%#-1), \"%s\"" ../usage.sp usage.rc
>
> into a batch file, then I changed the "%" to "%%" and ran it,
> and got the same (ie correct) results you did.
>
> Where is the makefile that has this command in it? I'll try
> changing the makefile to include two % to see if that fixes
> the problem.

I've found the makefile with the command in it, master.mif.
I've put some debug into wsplice and can see that the parameter
gets through fine when run as a batch file, but the first portion
of the "-f" parameter gets lost when run from wmake.

I'm now attempting to put some debug info into wmake to see
if it is actually sending out the full "-f" parameter.

BFN. Paul.


Arkady V.Belousov

unread,
Dec 4, 2006, 10:29:32 PM12/4/06
to
Hi!

Paul Edwards 05.12.06 2:10 wrote:

> --- ow/bld/wasm/test/test3/support.asm Tue Dec 05 06:51:08 2006
> ***************
> *** 0 ****
> --- 1,240 ----
> + ; support.asm - assembler support functions for DOS

[...]


> + public int86
> + int86 proc uses ax bx cx dx si di ds es, \
> + intnum:word, regsin:ptr, regsout:ptr
> + if @DataSize
> + lds si, regsin
> + else
> + mov si, regsin
> + endif
> + mov ax, word ptr [si + 0]
> + mov bx, word ptr [si + 2]
> + mov cx, word ptr [si + 4]
> + mov dx, word ptr [si + 6]
> + mov di, word ptr [si + 10]
> + mov si, word ptr [si + 8]

> + push bp


> + cmp intnum, 08h
> + jne not8

[...]
> + int86 endp


> + public int86x
> + int86x proc uses ax bx cx dx si di ds es, \
> + intnum:word, regsin:ptr, regsout:ptr, sregs:ptr

[...]
> + int86x endp

This is not good implementation:

- too fat;
- handles only part of all interrupt numbers;
- handles not all registers;
- doesn't allows to specify carry flag on input.

Recently, I prepare callint() and callint386() functions for Blair's CLIB.
Below 5 files:

- x86.h: definition of register structures and flags names;
- segread.c/segrd32.c: implementation of _segread()/_segread32() functions,
which read current segment registers into structure;
- callint.c/callin32.c: call any interrupt number (including INT25/26) with
any user specified register (except SS/SP/CS) and flags (including carry
flag). [Note, there is bugs in OW: "#pragma aux" doesn't allows to use
labels as offsets and it silently ignores "bp" in "modify[]" clause; this
all workarounded.]

Implementation details described in head comments (sorry for my bad
English); after implementation present code, which shows functions usage.
These functions are short, and they may be shortened even more, but Blair
thinks, that source readability is more important, than lesser size with
string instructions. Because of using #pragma aux, porting these C functions
to plain assembler shouldn't be hard.

X86.H
SEGREAD.C
SEGRD32.C
CALLINT.C
CALLIN32.C

Paul Edwards

unread,
Dec 4, 2006, 10:44:21 PM12/4/06
to
"Arkady V.Belousov" <a...@mos.ru> wrote in message news:el2ou1$90q$1...@www-1.scitechsoft.com...

> > + public int86x
> > + int86x proc uses ax bx cx dx si di ds es, \
> > + intnum:word, regsin:ptr, regsout:ptr, sregs:ptr
> [...]
> > + int86x endp

BTW, this is a testcase, it's not part of OW. :-)

> This is not good implementation:

I'm not an x86 expert as you can probably tell. :-)

> - too fat;
> - handles only part of all interrupt numbers;
> - handles not all registers;
> - doesn't allows to specify carry flag on input.

Ok.

> Recently, I prepare callint() and callint386() functions for Blair's CLIB.

I would like assembler code to be in an assembler file, not C.
And I need public domain code. If you would like to send me
a replacement support.asm (basically same interface), that is
public domain, I will use it in PDOS.

http://sourceforge.net/projects/pdos/

BFN. Paul.


Paul Edwards

unread,
Dec 4, 2006, 10:46:38 PM12/4/06
to
"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message news:el2hnm$6hh$1...@www-1.scitechsoft.com...

> I'm now attempting to put some debug info into wmake to see
> if it is actually sending out the full "-f" parameter.

I've tracked down the bug, it appears that Watcom is calling
an undocumented CreateProcessA(), which is causing the
string to be lost in Win98. Since it is undocumented, I can't
see if there is a reason for this. My own C library (PDPCLIB)
uses the documented CreateProcess(), and it doesn't have a
problem sending the string through. I'm about to try changing
sysnt.c to use CreateProcess() instead of CreateProcessA()
and see if that fixes the problem.

BFN. Paul.


Arkady V.Belousov

unread,
Dec 4, 2006, 11:23:08 PM12/4/06
to
Hi!

Paul Edwards 05.12.06 6:44 wrote:

>>> + int86x endp
> BTW, this is a testcase, it's not part of OW. :-)

But it tests not (in)efficiency of code, so why include such code, when
there exist better one?

>> Recently, I prepare callint() and callint386() functions for Blair's CLIB.
> I would like assembler code to be in an assembler file, not C.

Problem with external assembler files is, that they should be compiled
by (1) _additional_ external (for C/C++ compiler) assembler (which may not
be present) and that (2) it harder to support code correctness.

> And I need public domain code.

Blair's CLIB, for which I wrote callint(), is PD.

> If you would like to send me
> a replacement support.asm

Just compile given sources for each of 7 memory models (wcc -d1-m...
callint.c), then disassemble (wdis -a-fi-s callint.obj) - and you have pure
assembler sources. :)

> (basically same interface),

Issue with existing int86*() interface, which you try to imitate, is
that it itself too limited (not all registers, like BP, are present - but
this need, for example, for INT10/11xx functions; int86()/int86x() are
separate and duplicated), and that order of fields is incompatible with
PUSHALL/POPALL instructions. This is why structures was designed from scratch.

> that is
> public domain, I will use it in PDOS.

I myself prefer GPL, but in given case it may be used as PD.

Paul Edwards

unread,
Dec 4, 2006, 11:38:45 PM12/4/06
to
"Arkady V.Belousov" <a...@mos.ru> wrote in message news:el2s2h$9pv$1...@www-1.scitechsoft.com...

> >>> + int86x endp
> > BTW, this is a testcase, it's not part of OW. :-)
>
> But it tests not (in)efficiency of code, so why include such code, when
> there exist better one?

It's not testing efficiency of code, it's testing to see whether
masm can handle line continuations, macro expansions and
different memory models.

> >> Recently, I prepare callint() and callint386() functions for Blair's CLIB.
> > I would like assembler code to be in an assembler file, not C.
>
> Problem with external assembler files is, that they should be compiled
> by (1) _additional_ external (for C/C++ compiler) assembler (which may not
> be present) and that (2) it harder to support code correctness.

I like my C code to be standard, ie not using compiler extensions,
and my assembler to also be standard.

> > And I need public domain code.
>
> Blair's CLIB, for which I wrote callint(), is PD.

Can you give me a link to this please? I'd like to take some of the
math functions for use in PDPCLIB.

> > If you would like to send me
> > a replacement support.asm
>
> Just compile given sources for each of 7 memory models (wcc -d1-m...
> callint.c), then disassemble (wdis -a-fi-s callint.obj) - and you have pure
> assembler sources. :)

I'm after a single assembler source file which is aware of the
different memory models, using the features that have been
available in WASM now for almost -1 days. :-)

> > that is
> > public domain, I will use it in PDOS.
>
> I myself prefer GPL, but in given case it may be used as PD.

I want commercial companies to be able to use my code with no
strings attached. For your code to be PD it needs to have an explicit
PD notice on it. Code is copyrighted by default.

BFN. Paul.


Blair Campbell

unread,
Dec 5, 2006, 12:13:44 AM12/5/06
to
> > Blair's CLIB, for which I wrote callint(), is PD.
>
> Can you give me a link to this please? I'd like to take some of the
> math functions for use in PDPCLIB.

If you're talking about math.h functions, that's one header I haven't started on. And you should know that all of the modules that would need to be memory-model specific are only for the small memory model at present. But the url (although slightly outdated by now, some bugfixes and extra functions have been added since then) is http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/clib/fdclib.zip . Also bear in mind that in its current state it is highly OpenWatcom-specific and that in most of the cases where assembler is used, it is #pragma aux style. Oh and btw, some of the functions (like strtol) are borrowed from PDPCLIB :-).

Arkady V.Belousov

unread,
Dec 5, 2006, 12:29:39 AM12/5/06
to
Hi!

Paul Edwards 05.12.06 7:38 wrote:

>> Problem with external assembler files is, that they should be compiled
>> by (1) _additional_ external (for C/C++ compiler) assembler (which may not
>> be present) and that (2) it harder to support code correctness.
> I like my C code to be standard, ie not using compiler extensions,
> and my assembler to also be standard.

External assembler files are even more evil using "compiler
extensions". "More evil" because extension is external for compiler and even
less controllable by you. For example, there even harder to control calling
conventions correctness, especially if you plan to port source to different
compiler (else why to move inline assembler to external files?).

>>> And I need public domain code.
>> Blair's CLIB, for which I wrote callint(), is PD.
> Can you give me a link to this please? I'd like to take some of the
> math functions for use in PDPCLIB.

You should ask Blair for this, he develop and maintain CLIB.

>>> If you would like to send me
>>> a replacement support.asm
>> Just compile given sources for each of 7 memory models (wcc -d1-m...
>> callint.c), then disassemble (wdis -a-fi-s callint.obj) - and you have pure
>> assembler sources. :)
> I'm after a single assembler source file which is aware of the
> different memory models, using the features that have been
> available in WASM now for almost -1 days. :-)

Who prevents you to glue abovementioned sources through conditional
compilation and "simplified directives"?

>>> that is
>>> public domain, I will use it in PDOS.
>> I myself prefer GPL, but in given case it may be used as PD.
> I want commercial companies to be able to use my code with no
> strings attached. For your code to be PD it needs to have an explicit
> PD notice on it. Code is copyrighted by default.

I give you permission to insert PD notice in head if files. :) Also
note, copyright is different thing, than licensing.

Paul Edwards

unread,
Dec 5, 2006, 12:41:10 AM12/5/06
to
"Blair Campbell" <bl...@ified.ca> wrote in message news:20061204211344...@ified.ca...

> > > Blair's CLIB, for which I wrote callint(), is PD.
> >
> > Can you give me a link to this please? I'd like to take some of the
> > math functions for use in PDPCLIB.
>
> If you're talking about math.h functions, that's one header I haven't started on.

Damn. :-) Well Dave Wade has done most of the work already,
if you get the latest version of PDPCLIB out of CVS. He's just
missing atan2() and a proper implementation of modf(). So you
can use his stuff if you want. A new release is imminent, just
waiting on some MVS code to be added.

> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/clib/fdclib.zip .

Ok, thankyou! You might want to add a readme.txt to it. Glad to
see you have an explicit PD notice on the code.

> Also bear in mind that in its current state it is highly
> OpenWatcom-specific and that in most of the cases where
> assembler is used, it is #pragma aux style.

Ok.

> Oh and btw, some of the functions (like strtol) are borrowed from PDPCLIB :-).

Glad to see you found something of use from it. :-)

Good to see people now have a number of options for a PD C
runtime library. Another one is PDCLIB (as opposed to PDPCLIB).

BFN. Paul.


Paul Edwards

unread,
Dec 5, 2006, 12:57:22 AM12/5/06
to
"Arkady V.Belousov" <a...@mos.ru> wrote in message news:el2vv7$b28$1...@www-1.scitechsoft.com...

> Hi!
>
> Paul Edwards 05.12.06 7:38 wrote:
>
> >> Problem with external assembler files is, that they should be compiled
> >> by (1) _additional_ external (for C/C++ compiler) assembler (which may not
> >> be present) and that (2) it harder to support code correctness.
> > I like my C code to be standard, ie not using compiler extensions,
> > and my assembler to also be standard.
>
> External assembler files are even more evil using "compiler
> extensions". "More evil" because extension is external for compiler and even
> less controllable by you. For example, there even harder to control calling
> conventions correctness, especially if you plan to port source to different
> compiler (else why to move inline assembler to external files?).

Not sure why you say that. tasm/masm/wasm all enable the
standard stack conventions. I can mix and match assemblers
and compilers. E.g. I'm planning on using wasm as my
assembler and tc++ as my compiler, which are both free and
available as 16-bit DOS programs. But a company can choose
to use MASM instead and get proper support. I think this is
the correct way to do it. Assembler is a language, and C is a
language, and they need separate tools.

> > I'm after a single assembler source file which is aware of the
> > different memory models, using the features that have been
> > available in WASM now for almost -1 days. :-)
>
> Who prevents you to glue abovementioned sources through conditional
> compilation and "simplified directives"?

Nothing. I just need to do the work of figuring out how to
make it fit in with the existing interface, and supporting
multiple memory models.

> >>> that is
> >>> public domain, I will use it in PDOS.
> >> I myself prefer GPL, but in given case it may be used as PD.
> > I want commercial companies to be able to use my code with no
> > strings attached. For your code to be PD it needs to have an explicit
> > PD notice on it. Code is copyrighted by default.
>
> I give you permission to insert PD notice in head if files. :)

Ok.

> Also note, copyright is different thing, than licensing.

Yeah, but with PD there is no further licensing restrictions.
Companies shouldn't have to wade through the 52 licencing
conditions of GPL to see if they are violating any of them.
Or Open Watcom for that matter.

BFN. Paul.


Mat Nieuwenhoven

unread,
Dec 5, 2006, 1:03:51 AM12/5/06
to

I'll pick the Win98 games PC from my children and see if I can get the
build going.

Mat Nieuwenhoven


Bartosz Polednia

unread,
Dec 5, 2006, 1:56:28 AM12/5/06
to
It was my change to use CreateProcessA inside sysnt.c.

My investigations showed that Microsoft'a API defines

blahblahA as ANSI string version of blahblah
blahblahW as UNICODE string version of blahblah.


You can find info or exapmles here:

http://support.microsoft.com/kb/129796
or
http://www.andreavb.com/tip020004.html
or
http://source.winehq.org/source/dlls/kernel32/process.c
or
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp


Bartosz.

Michal Necasek

unread,
Dec 5, 2006, 3:00:42 AM12/5/06
to
Paul Edwards wrote:

> I've tracked down the bug, it appears that Watcom is calling
> an undocumented CreateProcessA(), which is causing the
> string to be lost in Win98. Since it is undocumented, I can't
> see if there is a reason for this. My own C library (PDPCLIB)
> uses the documented CreateProcess(), and it doesn't have a
> problem sending the string through. I'm about to try changing
> sysnt.c to use CreateProcess() instead of CreateProcessA()
> and see if that fixes the problem.
>

No, you are slightly confused. There is no CreateProcess API. There is
CreateProcessA and CreateProcessW. CreateProcess is a *macro* which
expands to either CreateProcessA or CreateProcessW.


Michal

Paul Edwards

unread,
Dec 5, 2006, 3:35:40 AM12/5/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:el38ue$e0d$1...@www-1.scitechsoft.com...

> Paul Edwards wrote:
>
> > I've tracked down the bug, it appears that Watcom is calling
> > an undocumented CreateProcessA(), which is causing the
> > string to be lost in Win98. Since it is undocumented, I can't
> > see if there is a reason for this. My own C library (PDPCLIB)
> > uses the documented CreateProcess(), and it doesn't have a
> > problem sending the string through. I'm about to try changing
> > sysnt.c to use CreateProcess() instead of CreateProcessA()
> > and see if that fixes the problem.
> >
> No, you are slightly confused. There is no CreateProcess API. There is

I was just going by what they published here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp

> CreateProcessA and CreateProcessW. CreateProcess is a *macro* which
> expands to either CreateProcessA or CreateProcessW.

Ok.

Regardless, I don't yet know why OW's implementation of system()
is different from mine, other than it is clearly able to run batch files,
so presumably somehow running the command processor.

I'll try to investigate further.

BFN. Paul.


Arkady V.Belousov

unread,
Dec 5, 2006, 3:54:40 AM12/5/06
to
Hi!

Paul Edwards 05.12.06 8:57 wrote:

>> External assembler files are even more evil using "compiler
>> extensions". "More evil" because extension is external for compiler and even
>> less controllable by you. For example, there even harder to control calling
>> conventions correctness, especially if you plan to port source to different
>> compiler (else why to move inline assembler to external files?).
> Not sure why you say that. tasm/masm/wasm all enable the
> standard stack conventions.

In Watcom there is different calling convention. And if you forget to
explicitly specify "cdecl" calling convention (and, thus, making worser
code), you under trouble.

>>> I'm after a single assembler source file which is aware of the
>>> different memory models, using the features that have been
>>> available in WASM now for almost -1 days. :-)
>> Who prevents you to glue abovementioned sources through conditional
>> compilation and "simplified directives"?
> Nothing. I just need to do the work of figuring out how to
> make it fit in with the existing interface, and supporting
> multiple memory models.

Just read sources: here supported memory models (see #if defined) and
porting to plain assembler is easy (just remove quotes around instructions
in #pragma aux). There remains only one task: convert one-line callint()
C-function to assembler function, and correctness of this conversion you may
test by code inside #ifdef TEST/#endif.

>> Also note, copyright is different thing, than licensing.
> Yeah, but with PD there is no further licensing restrictions.
> Companies shouldn't have to wade through the 52 licencing
> conditions of GPL to see if they are violating any of them.

There is not "52 licensing conditions". All easy: if you make
derivative work (your program based on GPL-ed _sources_), then your program
also should be GPL-ed (ie., released in sources and there shouldn't be
restrictions in accessing and (re)distributing both program executable(s)
and sources). If your program just _uses_ (calls) GPLed program, then there
is no restrictions, how you may license your program.

Michal Necasek

unread,
Dec 5, 2006, 3:59:56 AM12/5/06
to
Paul Edwards wrote:
> I was just going by what they published here:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
>
Right near the bottom: "Implemented as CreateProcessW (Unicode) and
CreateProcessA (ANSI)." Microsoft probably assumes that what I said
earlier about the A/W functions is common knowledge and everyone is
aware of it. It's something I probably read in some book 10+ years ago
but I have no idea where MSDN documents that little tidbit.

> Regardless, I don't yet know why OW's implementation of system()
> is different from mine, other than it is clearly able to run batch files,
> so presumably somehow running the command processor.
>

See my other post (yes, it does run the command processor). And it's
not just batch files, it's internal shell commands too.


Michal

Peter C. Chapin

unread,
Dec 5, 2006, 7:27:30 AM12/5/06
to
"Arkady V.Belousov" <a...@mos.ru> wrote in
news:el3bvk$g00$1...@www-1.scitechsoft.com:

> In Watcom there is different calling convention. And if you

> forget to...

I'm not sure why there is this big discussion regarding regression test
cases... unless I'm misunderstanding something. The point of a regression
test is to exercise some certain aspect of the program under test... not to
write realistic or useful code. In fact, writing inefficient or "stupid"
code is probably good to do now and then in a regression test suite. After
all, real users write such code and wasm should be able to assemble it.

In the OWSTL test suite I try to use various approaches in the code. Some
techniques are not very smart, but they are all legal. However, if I always
used the same methods, the breadth of the test suite would be reduced and
its quality as a test suite would be less.

Peter

Peter C. Chapin

unread,
Dec 5, 2006, 7:31:15 AM12/5/06
to
"Mat Nieuwenhoven" <mni...@dontincludethis.zap.a2000.nl> wrote in
news:zavrhjqbagvapyhqrguvf...@news.openwatcom.org:

> I'll pick the Win98 games PC from my children and see if I can get the
> build going.

To be honest, I wouldn't suggest spending a lot of time getting the build
to work on Windows 9x. In addition to being obsolete, those systems are
dead ends. Supporting the build on 32-bit DOS is more useful in my view,
even though DOS is older, because DOS is still used in situations where no
other system will do.

I'd hate to see the build get more complicated, less understandable, or
less extensible in the future (to new systems) in an effort to support
Windows 9x. To my mind that would be a step backwards.

Peter

Michal Necasek

unread,
Dec 5, 2006, 9:39:12 AM12/5/06
to

Sorry, I have not managed to apply your patch. I had to fix up the
source files that were screwed up and put them into the state they were
in last week.

Please re-create the patch against current source and re-send it, *or*
simply send me the modified files (ZIP archive is preferable). Make very
sure there are no hard tabs in C source files. Maybe I just can't use
patch or the diff got mangled somehow during transfer, but I will
probably have easier time diffing the files myself. I'm almost sure
there were some hard tabs in the patch that didn't make it, so if you
zip up the patch too, it might work better.


Michal

Bartosz Polednia

unread,
Dec 5, 2006, 9:51:15 AM12/5/06
to
Michal Necasek napisał(a):

>
> Sorry, I have not managed to apply your patch. I had to fix up the
> source files that were screwed up and put them into the state they were
> in last week.
>

The word "WERE" is in the proper tense as wasm was working again
before your changes.

Bartosz.

Rod Pemberton

unread,
Dec 5, 2006, 10:05:45 AM12/5/06
to

"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message
news:el30vt$bcm$1...@www-1.scitechsoft.com...

> "Blair Campbell" <bl...@ified.ca> wrote in message
news:20061204211344...@ified.ca...
> > > > Blair's CLIB, for which I wrote callint(), is PD.
> > >
> > > Can you give me a link to this please? I'd like to take some of the
> > > math functions for use in PDPCLIB.
> >
> > If you're talking about math.h functions, that's one header I haven't
started on.
>

Paul,

For PD math functions, you could also look at Libnix's math functions (avoid
MorphOS versions - copyrights) or Fred Fish's math library. IIRC, the Mingw
C library is PD but it's been mostly converted to assembly. I don't recall
if MINGW contained some of Sun Microsystems copyleft FDLIBM.

PD Libnix sources:
http://sourceforge.net/projects/libnix/
http://zapek.com/software/libnix/

Fred Fish's PD math library net.sources 1987, shr archives:
0 http://groups.google.com/group/net.sources/msg/3e8a75e4831c0f8c?hl=en
1b http://groups.google.com/group/net.sources/msg/f09b3693745439c2?hl=en
2 http://groups.google.com/group/net.sources/msg/e943062492e05539?hl=en
3 http://groups.google.com/group/net.sources/msg/6167d8c8a3abc669?hl=en
4 http://groups.google.com/group/net.sources/msg/f710a479c21cec64?hl=en
5 http://groups.google.com/group/net.sources/msg/8157266fe1c32dc2?hl=en
6 http://groups.google.com/group/net.sources/msg/8ee586fa7bf4354a?hl=en


Rod Pemberton


Paul Edwards

unread,
Dec 5, 2006, 4:35:07 PM12/5/06
to
"Rod Pemberton" <do_no...@bitfoad.cmm> wrote in message news:el41qq$r8b$1...@www-1.scitechsoft.com...

Thankyou! I now have atan2 and modf, which means I have
something for every function, even if it isn't properly
implemented.

BFN. Paul.


Paul Edwards

unread,
Dec 5, 2006, 4:42:53 PM12/5/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:el409j$qc2$1...@www-1.scitechsoft.com...

>
> Sorry, I have not managed to apply your patch. I had to fix up the
> source files that were screwed up and put them into the state they were
> in last week.

There was no need to change anything. That patches I gave you
were against the latest source.

> Please re-create the patch against current source and re-send it, *or*
> simply send me the modified files (ZIP archive is preferable). Make very
> sure there are no hard tabs in C source files. Maybe I just can't use
> patch or the diff got mangled somehow during transfer, but I will
> probably have easier time diffing the files myself. I'm almost sure
> there were some hard tabs in the patch that didn't make it, so if you
> zip up the patch too, it might work better.

I checked, and there were no hard tabs in the source code I
sent you. There were only hard tabs in the diff headers and
the disassembly output.

Anyway, I will send you new diffs against the latest source
as a zip file. It'll take about an hour to import the latest
source and recheck it, so stand by. :-)

BFN. Paul.


Paul Edwards

unread,
Dec 5, 2006, 7:45:22 PM12/5/06
to
"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message news:el2a3p$4u2$1...@www-1.scitechsoft.com...

> I am unable to run the wcc regression test cases because I am
> unable to build wcc.

Now that I have found out that wcc resides in
dos386.386\wcc386c.exe rather than nt386, I have been able
to run the wcc regression tests and they all pass.

> I am unable to test that the build works,
> because I am unable to build the build.

And while I get lots of errors building the build, I still manage
to produce a wcc386c.exe, so it would appear that my wasm
changes have not broken the build.

BFN. Paul.


Mat Nieuwenhoven

unread,
Dec 6, 2006, 1:02:47 PM12/6/06
to
On Tue, 5 Dec 2006 10:53:16 +1100, Paul Edwards wrote:

<snip>

I think wsplice supports the @filename argument, where it takes the
arguments fro a file. That would remove any dependency on the command
processor.

Mat Nieuwenhoven


Mat Nieuwenhoven

unread,
Dec 6, 2006, 3:32:56 PM12/6/06
to

Indeed it does, there are a number of .mif files which already do this,
like bld\wic\mif\master.mif. If in bld\sdk\rc\rc\mif\master.mif I replace

wsplice -kENGLISH -kIS_RC -k$(host_os) $(splice_opts) -t8 -f
"%+(MSG_USE_E_BASE+%$#-1), \"%s\"" ../usage.sp usage.rc

with two lines

@%write usagee.tmp -kENGLISH -kIS_RC -k$(host_os) $(splice_opts) -t8 -f
"%+(MSG_USE_E_BASE+%$#-1), \"%s\"" $< $^@
wsplice @usagee.tmp

then the generated file looks OK and the Win98 build passes this part. It
still gives errors later on, which I don't have time to look at tonight.
Also, there are some other .mif / makefiles that require the same
treatment: bdiff\master.mif, wasm\mif\master.mif, wtouch\master.mif,
wv\master.mif, wstrip\master.mif , maybe cc\master.mif .

Mat Nieuwenhoven


Mat Nieuwenhoven

unread,
Dec 6, 2006, 3:37:40 PM12/6/06
to
On Tue, 5 Dec 2006 12:31:15 +0000 (UTC), Peter C. Chapin wrote:

>"Mat Nieuwenhoven" <mni...@dontincludethis.zap.a2000.nl> wrote in
>news:zavrhjqbagvapyhqrguvf...@news.openwatcom.org:
>
>> I'll pick the Win98 games PC from my children and see if I can get the
>> build going.
>
>To be honest, I wouldn't suggest spending a lot of time getting the build
>to work on Windows 9x. In addition to being obsolete, those systems are
>dead ends. Supporting the build on 32-bit DOS is more useful in my view,
>even though DOS is older, because DOS is still used in situations where no
>other system will do.

Like FreeDos? Or do you mean things like HXDOS? Too bad I allocated my
FreeDos partition way too small for that. I'll take a look after the Win98
thing.

>I'd hate to see the build get more complicated, less understandable, or
>less extensible in the future (to new systems) in an effort to support
>Windows 9x. To my mind that would be a step backwards.

I (for now) don't think it will require many changes to get it working
under Win98. Some of these changes might be required for DOS as well, like
using "wsplice @filename" to bypass shell peculiarities.

Mat Nieuwenhoven


Peter C. Chapin

unread,
Dec 6, 2006, 3:49:03 PM12/6/06
to

> I (for now) don't think it will require many changes to get it working


> under Win98. Some of these changes might be required for DOS as well,
> like using "wsplice @filename" to bypass shell peculiarities.

Yes, if the changes actually make the build *more* general then that
certainly seems like a good thing. I'd just hate to see Win9x specific
oddities added that might later cause problems. Win9x just isn't worth it
in my view.

Peter

Mat Nieuwenhoven

unread,
Dec 6, 2006, 11:59:40 PM12/6/06
to

Indeed. However, if making a Win98 build working gets someone going on
re-creating wgml .... :-)

Mat Nieuwenhoven


Arkady V.Belousov

unread,
Dec 8, 2006, 8:21:20 AM12/8/06
to
Hi!

Rod Pemberton 05.12.06 18:05 wrote:

"
It appears that Part 1 of 6 of the pml posting was truncated or lost
because it exceeded 64000 characters; *NOT* 64K (???). Anyway, I've
split the contents up into two postings, Part 1a and Part 1b.
"

Looks like you miss one URL. I was (shortly) try to find 1a post, but
without success. :(

Arkady V.Belousov

unread,
Dec 8, 2006, 8:44:23 AM12/8/06
to
Hi!

Arkady V.Belousov 08.12.06 16:21 wrote:

Oops, accidentally I found missed URL for 1a/6 post:

http://groups.google.com/group/net.sources/msg/acba331beb2d55d0?hl=en

Rod Pemberton

unread,
Dec 8, 2006, 10:08:55 AM12/8/06
to

"Arkady V.Belousov" <a...@mos.ru> wrote in message
news:elbq2m$r9g$1...@www-1.scitechsoft.com...

Yes, good job.

Sorry, I assumed 1b was a complete repost.

1b is Message-ID: 3...@mcdsun.UUCP so 1a is 3...@mcdsun.UUCP in Google Groups
advanced search.


One more .shr to extract ... :(


Rod Pemberton


Paul Edwards

unread,
Dec 9, 2006, 11:33:08 AM12/9/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:el409j$qc2$1...@www-1.scitechsoft.com...

Michal, I have tested the 2006-12-09 daily snapshot, and it is
working for my purposes.

I also ran through small/large/flat tests of 386 and non-386 to
check that the offsets were the same as masm.

I also tested that lengthof worked.

Thanks for helping me with this. Your code changes were
much neater than mine. I look forward to the official 1.6
release, but there's no rush - probably better to wait for that
"restrict" change to come through so that OW is more
useful to others.

BFN. Paul.


Michal Necasek

unread,
Dec 9, 2006, 11:58:14 AM12/9/06
to
Paul Edwards wrote:

> Michal, I have tested the 2006-12-09 daily snapshot, and it is
> working for my purposes.
>

Good.

> Thanks for helping me with this. Your code changes were
> much neater than mine.
>

You're welcome. I may know the Open Watcom source better than most.
But you have a very important ability that seems surprisingly rare among
programmers: the ability to drill down in a large project and locate the
piece of code responsible for certain behaviour.

Out of curiosity, how do you navigate the code? Do you use some sort
of static analysis tools? The debugger? Something else?

> I look forward to the official 1.6
> release, but there's no rush - probably better to wait for that
> "restrict" change to come through so that OW is more
> useful to others.
>

I'm not waiting for that or it'd get never released - it's late enough
as it is, and it's only supposed to be a bugfix release :) See
http://www.openwatcom.org/ftp/devel/ (RC3).


Michal

Paul Edwards

unread,
Dec 9, 2006, 1:17:12 PM12/9/06
to
"Michal Necasek" <mic...@prodigy.net> wrote in message news:elepu8$38l$1...@www-1.scitechsoft.com...

> > Thanks for helping me with this. Your code changes were
> > much neater than mine.
> >
> You're welcome. I may know the Open Watcom source better than most.
> But you have a very important ability that seems surprisingly rare among
> programmers: the ability to drill down in a large project and locate the
> piece of code responsible for certain behaviour.

Yes, I don't like to be beaten by the machine. I live in fear
of the bug that will exceed my capability to find.

> Out of curiosity, how do you navigate the code? Do you use some sort
> of static analysis tools? The debugger? Something else?

Nope, just micro-emacs and grep on the command line. I
didn't get organized enough to find out how to switch on
the debugger in the makefiles, so I just used printfs.

I would have got organized with the debugger had I got a
core dump. That would have been worth the effort.

> > I look forward to the official 1.6
> > release, but there's no rush - probably better to wait for that
> > "restrict" change to come through so that OW is more
> > useful to others.
> >
> I'm not waiting for that or it'd get never released - it's late enough

Late? There was over a 1 year gap between 1.3 and 1.4.
1.5 was only released in May.

> as it is, and it's only supposed to be a bugfix release :) See

Ok.

> http://www.openwatcom.org/ftp/devel/ (RC3).

Ok. So this is still another beta? When is the official 1.6
due out?

BFN. Paul.


Arkady V.Belousov

unread,
Dec 9, 2006, 3:01:38 PM12/9/06
to
Hi!

Paul Edwards 09.12.06 21:17 wrote:

>> I'm not waiting for that or it'd get never released - it's late enough
> Late? There was over a 1 year gap between 1.3 and 1.4.
> 1.5 was only released in May.

Michal was decide to earlier release of 1.6, because he feels, that in
1.5 too many things was broken, and he remark in announces for RC1, that it
will be mainly bugfix release.

Arkady V.Belousov

unread,
Dec 9, 2006, 4:01:44 PM12/9/06