BxbAsm

[jcfuller]

Steve,
  Here is my complete Bxbasm project directory. The exe is named BxbAsm5_10.exe with BxbAsm5_10.c the
main source file compiled with gcc. I fixed all the comment warnings but there are still warnings for unused variables.

James

[jcfuller]

James,
just on a hunch, I thought I'd run this code, (that causes an error), thru an earlier version of bxbasm that assembles using Masm:

Steve,
  I'm confused here. Bxbasm is written in "c" and it crashed when trying to translate the snippet I posted. Nothing to do with masm/jwasm is there? Unless the translation code is different??

James
 

[SteveA]

I'm confused here. Bxbasm is written in "c" and it crashed when trying to translate the snippet I posted.
Nothing to do with masm/jwasm is there? Unless the translation code is different??

It never crashed on translation, on my end.
It translated, assembled and linked without error of any kind.
It did, however, thro an exception on execution.

That is what confused me, even tho' I could find no error in the code.
That prompted me to try assembling with Masm.
Which succeeded, without error of any kind and executed without error.

[SteveA]

Isn't the library warning primarily the result of using the LCCWin32 console library?

I don't think it is.
Lcc must be inserting an instruction of some sort into the .obj.

[SteveA]

James,
this from Jacob:

From: jacob navia <ja...@spamsink.net>
> 3. See if there is some way to get the compiler to not generate the
> 'library' directives (does it not do so for certain other .c sources

That -library directive is produced by the
#pragma lib <foo.lib>

found in certain lcc headers. It instructs the compiler to produce a comment section in the object file that will tell the linker to include
that library in the link.


In this way, I avoid the thousands of questions of newbees that tell me

"I included the header file but now the compiler tells me:
   undefined symbol _SomeLibraryCall. What do I do now?"

WORKAROUND: (Bad solution)

Eliminate all the #pragma lib istructions form the header files.


SECOND WORKAROUND: (Better solution)

Fix your linker so that follows the -library comments in object files
and includes transparently a library in the link from the .h file.

[SteveA]

Here is my complete Bxbasm project directory.
The exe is named BxbAsm5_10.exe with BxbAsm5_10.c the main source file compiled with gcc.

James,
I ran Test48x2 using BxbAsm5_10.exe.
It functioned exactly like my compile, (using lcc), it translated and executed.
It stores the correct values to test.txt and it stalls, just like mine does, at the end of the program.

Steve

[jcfuller]

That is what confused me, even tho' I could find no error in the code.
That prompted me to try assembling with Masm.
Which succeeded, without error of any kind and executed without error.

Steve,
  Did you try jwasm with -Zg ?

James

[SteveA]

Did you try jwasm with -Zg ?

No, but I'll give it a try.

Another thing I'm interested in, is looking at the assembly listing file.
That might reveal something I've missed.

[SteveA]

James,
In an effort to find out what is broken, I've gone back to recent, older versions of bxbasm.
Since the compile from January worked without producing any error, I wanted to narrow down the possibilities.
It looks like bxbasm worked when only a minimum of functions resided in bxblib.lib and most of bxb's functions were in file: Afunct.c.

So, what that tells me is, that somewhere along the line, I introduced an error when I converted functions from .C to .asm and constructed the new bxblib.lib.
At this point, I need to back-step that process and re-test each function that goes into bxblib.lib.
That is what I will be working on until I get this thing figured out.

Steve

[jcfuller]

Steve,
  I am having pretty good luck with the port but found an issue with the translation process of the bas -> asm.
Test46 is throwing an exception. If I comment out the PUT 1,1 it will not throw an exception. Note that the asm file IS created.

I ran valgrind against it and this is the report it gave.

Code: [Select]

==8105== 1 errors in context 1 of 2:
==8105== Conditional jump or move depends on uninitialised value(s)
==8105==    at 0x805AF59: Do_field (AFile.c:865)
==8105==    by 0x806299C: parser (Bxbasm.c:177)
==8105==    by 0x8062828: pgm_parser (Bxbasm.c:86)
==8105==    by 0x80627E7: main (Bxbasm.c:67)
==8105==  Uninitialised value was created by a stack allocation
==8105==    at 0x804D4A7: find_strng (Utility.c:388)
==8105==



James

[SteveA]

James,
I've made at least one discovery.
There are a few functions that need to be put back into Bxbasm.inc

Code: [Select]

;/* Bxbasm.INC */
;
; *************BxbAsm Compiler*************
; Copyright: sarbayo (c) 2004-2012
; =========================================================================
    .386
    .code

; «««««««««««« FUNCTIONS «««««««««« FUNCTIONS «««««««««« FUNCTIONS ««««««««
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
StdIn proc lpszBuffer:DWORD,bLen:DWORD
    LOCAL hInput :DWORD
    LOCAL bRead  :DWORD
;
    invoke GetStdHandle,STD_INPUT_HANDLE
    mov hInput, eax
;
    invoke SetConsoleMode,hInput,ENABLE_LINE_INPUT or ENABLE_ECHO_INPUT or ENABLE_PROCESSED_INPUT
    invoke ReadFile,hInput,lpszBuffer,bLen,ADDR bRead,NULL
    mov eax, bRead
    ret
StdIn endp
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
StrLen proc item:DWORD
    push    ebx
    push item
    call strlen
    pop     ebx
    ret
StrLen endp
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
StdOut proc lpszText:DWORD
    LOCAL hOutPut  :DWORD
    LOCAL bWritten :DWORD
    LOCAL sl       :DWORD
;
    invoke GetStdHandle, STD_OUTPUT_HANDLE
    mov hOutPut, eax
    invoke StrLen, lpszText
    mov sl, eax
    invoke WriteFile, hOutPut, lpszText, sl, ADDR bWritten, NULL
    mov eax, bWritten
    ret
StdOut endp
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««


They will need to be removed from bxblib.lib, as well.
For some odd reason, this fixes the problem with: Test48X2.bas.

I don't know if it will fix the other issues, but, let's see what effect it has.

Steve

[jcfuller]

Steve,
  While waiting for you to get your new computer I decided to convert your Bxbasic tutor source to MinGW gcc. I think I got it from the QDepartment file section?
First problem was global var omissions in Engine.c of Chapter04.


I added:
    char var_type;           /* current variable type             */
    double *dv_stack;          /* stack:double float values         */
    char **dn_stack;         /* stack:double float names          */
    int dmax_vars=0;        /* stack:double float counter        */

and it compiled fine

James

 

[SteveA]

Hey James,
Okay,... it's taking me forever to get Win7 setup....
Boy, I hate when Microsoft feel the need to constantly re-invent the wheel.

Anyway...the first thing I've done, is to copy over my working directories for Lcc and Jwasm.
So far, as far as I can tell, I am having no problems getting bxbasm to work.

I took the same bxbasm, compiled with Lcc and had it translate and assemble with jwasm.
Executable appears to be working without errors.
Zero warnings, zero errors.
(just the same old lcc caused linker warning: "unknown directive -library..."


edit:
not saying it's all good, just that I have only just started testing.

[SteveA]

James,
I played around with some of the scripts that have been troublesome.
I have narrowed down that "clear" is adversely affected by the strings that contain floating point numbers.
Like: LSET mystr$ = MKD$(floatVal#)
For some reason, this causes an exception.

However, if I go in (right-click on: test#?.exe) and set the Compatibility Mode for either Win-95 or Win-98, then no errors are generated.
The executable executes and terminates normally. This I don't understand.

I am not having any troubles with the Bxbasm executable, as to failing to translate the scripts or hanging in the process.
Bxbasm seems to be working as expected.

What I've got to figure out is what makes clearing the above mentioned strings throw an exception.
Maybe I've got to redesign that procedure.

Steve

[jcfuller]

Steve,
  Would there be any free/reallocate involved? I can't track it down but I believe Win7 is very fussy on free, maybe even to the point of an actual bug?? I did a number of searches but couldn't come up with a definitive answer.

James