• Please review our updated Terms and Rules here

GW-BASIC released as open source

Don't know what happened to my original comment, but this must be a very early 8086 version of GWBASIC. The code is auto-translated from 8080, with an enormous amount of excess baggage. It looks as if it comes from Intel CONV86 under "strict" mode. As an example, let's take ADVGRP.ASM at around line 360:

Code: 
	MOV	BX,QUEINP
	CALL	WRAP		;CHECK FOR WRAP AROUND CASE
	POP	DX
	MOV	BYTE PTR [BX],DL
	LAHF
	INC	BX
	SAHF
	MOV	BYTE PTR [BX],DH
	LAHF
	INC	BX
	SAHF
	MOV	BYTE PTR [BX],CL
	LAHF
	INC	BX
	SAHF
	MOV	BYTE PTR [BX],CH
	LAHF
	INC	BX
	SAHF
	POP	DX
	MOV	BYTE PTR [BX],DL
	LAHF
	INC	BX
	SAHF
	MOV	BYTE PTR [BX],DH
	LAHF
	INC	BX
	SAHF
	MOV	QUEINP,BX
	RET

Only an automatic converter would generate code like this. Let's see what human-generated code might look like:

Code: 
        MOV	BX,QUEINP
	CALL	WRAP		;CHECK FOR WRAP AROUND CASE
	POP	[BX]
        MOV        [BX+2],CX
        POP        [BX+4]
        ADD        BX,6
        MOV       QUEINP,BX

The giveaway is the pairs of LAHF/SAHF instructions (not common in 8086 native code) around the INC BX instructions to preserve the flags. In this case, they serve no purpose, as the setting of the flags has no effect on the code.
 
I tried to compile GW-BASIC from sources but failed. It seems to me that part of the code is missing...
First of all, I converted files from UNIX-like <LF> style to DOS <CR><LF> because some assemblers went crazy. I tried to use: Intel ASM86 ver 3.1 / 3.2, Digital Research CP-M 8086 Assembler ver 1.1, MASM v1.0, MASM v3.0, MASM v4.0, MASM v5.0 and Borland TASM v4.1. It seemed to me the most correct is working with the source code of version 4 of the MASM. Then i created a makefile where i collected all the assembler files. I had to fix it a little bit in the code:
Code: 
GWEVAL.ASM line 452: MOV	DX,OFFSET 256*100+OPCNT replaced to MOV	DX,25600+ OFFSET OPCNT

Also i concatinate files MATH1.ASM and MATH2.ASM in new large file named MATH.ASM and make some fixes:
Code: 
MATH.ASM line 1311: MOVS	?CSLAB,WORD PTR ?CSLAB replaced to MOVSW
MATH.ASM line 5020: MOVS	?CSLAB,WORD PTR ?CSLAB replaced to MOVSW
MATH.ASM line 5022: MOVS	?CSLAB,WORD PTR ?CSLAB replaced to MOVSW

Now compilation passes without errors, but the main file is not collected due to the lack of definitions of some procedures:
Code: 
Unresolved externals:


MAPSUP in file(s): 
 GIOKYB.OBJ(GIOKYB)
POKFLT in file(s): 
 GWMAIN.OBJ(GWMAIN)
SCRINP in file(s): 
 SCNDRV.OBJ(SCNDRV) GWSTS.OBJ(GWSTS)
POLLEV in file(s): 
 GWSTS.OBJ(GWSTS)
TRMCOM in file(s): 
 GIOCOM.OBJ(GIOCOM)
SCRATR in file(s): 
 GWSTS.OBJ(GWSTS)
SETCLR in file(s): 
 GWSTS.OBJ(GWSTS)
PNTINI in file(s): 
 ADVGRP.OBJ(ADVGRP)
SCROUT in file(s): 
 SCNDRV.OBJ(SCNDRV) GWSTS.OBJ(GWSTS)
SETATR in file(s): 
 ADVGRP.OBJ(ADVGRP) GENGRP.OBJ(GENGRP)
CSRDSP in file(s): 
 GIOKYB.OBJ(GIOKYB) GWSTS.OBJ(GWSTS)
...etc...
 
It would be interesting to do a disassembly of the gw-basic that shipped with ms-dos to see if matches.
I may have to do that....

joe
 
Someone commented on the page of the announcement with a similar experience:

Diomidis Spinellis said:
After making a few changes I was able to assemble all files with MASM 5.10A. You can find them, together with a rough Makefile and a linker script, in this repo. Slightly earlier MASM versions might have also worked, but initially I was moving from one MASM version to the next, trying to find one that would assemble all files without an error. In the end, I fixed a few issues by hand. Sadly, many routines are missing from the source code. It seems to me that this source code was coupled with an OEM vendor-specific file that performed low-level stuff, such as clearing the screen.
Click to expand...

I wonder if it’s possible to write a few of those low-level routines from scratch (eg clearing the screen does not sound hard) and eliminate others (eg printing?) to get it to produce an executable...
 
Chuck(G) said:
Only an automatic converter would generate code like this.
Click to expand...

I did notice this, but there are also very human-produced bits of code, like REP MOVSW which no converter would produce. So maybe it was a human-assisted transcode.

Seeing the very unoptimal stretches of code makes me wonder if gwbasic could be optimized to be significantly faster.
 
You must log in or register to reply here.
Back
Top