BxbAsm

[SteveA]

Thanks for the SF link.
I downloaded v-461.
I'll see what I can make of it.

[SteveA]

Code: [Select]

<snip>
jwasm -elf %1.asm
ld  %GCCCFL% -s -o %1.exe %1.obj -L%LIB% -lbxbasmlib -lmingw32 -lmsvcrt -lkernel32 -luser32 -lgdi32 -lcomctl32 -ladvapi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32 -lwinmm -lcomdlg32 -limagehlp -lversion

Hey James,
Once Bxbasm is compiled, I don't want it to be dependant on Mingw, beyond that point.

With the Masm32 setup, all that was required was that the end-user install Masm32 and possibly any updates.
If I switch to JWasm, I don't want to force the end-user to also install Mingw (for the linking).
That is why I'm trying to figure a way to make the Mingw headers and libraries work with JWasm, (if you get my drift).

((On a side note (re: drizz) why do some people have to turn a simple question into a pissing contest, Jeez !?))

JWasm seems very limited in what it has available in terms of includes and libraries.
I don't want to wait for japheth to expand those items.
I'd rather do it myself, if someone else hasn't already.

I'm also working on getting the missing macros and functions incorporated, too.
That's not too hard to do, since I know what I need.

Oh, I forgot to mention,
I asked japheth about the mingw headers and libs.
He indicated that they might be made to work, but there are subtle differences between MS and Mingw.
He too suggested linking with LD if I chose to go that route.
I suppose LD.exe could always replace JWlink.exe in the final distro.
Hmm, your thoughts ?

[jcfuller]

Steve,
  From the Masm forum you have all the links to the tools to create your own.
It really depends on where you want to go with BxbAsm.
It you are even contemplating a Linux version I'd say stick with MinGW and only use the "c" runtime calls. No Windows API calls at all or wrap them with your own that can be swapped out for a Linux version.


James

 

[SteveA]

From the Masm forum you have all the links to the tools to create your own.

I tried using some of the conversion tools (h-to-inc, def-to-lib)
They don't always produce the desired results.
The product seems to generate errors.

[jcfuller]

Well just how many proto's and libraries do you really need  to support the Bxbasm language?
Just use the MinGW setup for developing BxbAsm in c (should be c++ in my opinion but I'm class happy .
You can always borrow some of the individual macros and routines from m32lib and recompile with jwasm ( that shouldn't bother Steve that much - he's more worried on wholesale appropriation of the whole library)

James

[SteveA]

Well just how many proto's and libraries do you really need  to support the Bxbasm language?

I don't want the language to be limited to where it is at this point.
The reason for resuming the project is to expand the language capabilities.
Today, Bxbasic (the interpreter) far exceeds the abilities of Bxbasm.

The resulting windows.inc, after running windows.h thru h2incx generates errors with jwasm. Too bad.
Japheth does state that it doesn't work perfectly.
H2INC (original microsoft version) fails completely. I don't even know why MS ever released it.

[John]

Just use the MinGW setup for developing BxbAsm in C

I agree with James on this. I think what the user of BxAsm is looking for is a way to turn HIS BxBasic code into ASM source. I would prefer if BxASM used .h files for external libraries and system API calls for flexibility and portability.

[jcfuller]

I don't want the language to be limited to where it is at this point.
The reason for resuming the project is to expand the language capabilities.
Today, Bxbasic (the interpreter) far exceeds the abilities of Bxbasm.

How is the language going to limited? You know as you create new functionality what you need for library support. Just add the protos then for a new release. Unless of course you are going to allow in line assembler within basic source? If so I think it's the users responsibility.

James

[jcfuller]

Steve,
  Maybe tcc has something you can use?
http://bellard.org/tcc/

James

[jcfuller]

Why not start with just the "c" runtime functions.
This may not be a complete list but as a "c" programmer you probably know already.
James

Code: [Select]

<process.h>
 <conio.h>
 <direct.h>
 <io.h>
 <ctype.h>
 <fcntl.h>
 <math.h>
 <stdio.h>
 <string.h>
 <stddef.h>
 <stdlib.h>
 <setjmp.h>
 <time.h>
 <stdarg.h>
 <sys/types.h>
 <sys/stat.h>
 <unistd.h>


[SteveA]

... Unless of course you are going to allow in line assembler within basic source?

Actually, that is already an intrinsic function of Bxbasm.

   ASM                     passes assembly language code to the assembler

=======================================================================
ASM Command
ASM mov  eax, [esi]

ASM is not a standard Basic command, but, Bxbasic passes along to the assembler any statement that follows the ASM command.
Bxbasic does not syntax check the ASM text string.

=======================================================================

Bxbasm has had the ability to dynamically use any assembly language command or API function from day one.

John will recall..., it took me forever to find out how, (with the help of others here on this forum), an interpreter could dynamically call API functions. Which Bxbasic (the interpreter) can now do.

[jcfuller]

Steve,
  One addition I would like to see is in BsbAsm is directives ala Bcx.
With Bcx there is the $ONEXIT directive: $ONEXIT "GCTD.BAT $FILE$"
This directive shells to the batch file GCTD.BAT passing the currnet filename (no extension) after translation is complete.
There are several others that would also prove very useful.

James

[SteveA]

I'm having some difficulty getting JWlink to link a .lib file, that I have created, that would contain some routines.
I have exchanged messages with japheth about this, but, I have no solution yet.

The .lib file is created with C. It takes a function name ( testlib() ) and decorates it like so ( _testlib@0 ).
japheth had me do a "dumpbin" on the .lib file and every thing looks ok.
The problem is, that jwlink can't seem to see (or find) the function name.

Still working on it.

[jcfuller]

Steve,
  I thought I'd try jwlink with a couple c routines in a library.
Everything works fine using gcc to create the object files and ar to create the library.
James

c sources:
jcf17.c

Code: [Select]


int jcftest17 (void);

int jcftest17 (void)
{
  int      i;
  i= 17;
  return i;
}

jcf18.c

Code: [Select]


int jcftest18 (void);

int jcftest18 (void)
{
  int      i;
  i= 18;
  return i;
}

I was using MinGWTDM64 hence the -m32
compiled with:
gcc -c jcf17.c -m32
gcc -c jcf18.c -m32

created the library with:

ar rcs libjcflib.a jcf17.o jcf18.o

This is the jwasm asm source:

Code: [Select]

                       ;
;+---------------------------+
;|  use CRT (MSVCRT) in ASM  |
;+---------------------------+

.386
.MODEL FLAT, stdcall
option casemap:none
     public _start

WIN32_LEAN_AND_MEAN equ 1
include \jwasm\wininc\include\windows.inc
include \jwasm\wininc\include\stdio.inc


 ;my c functions
 jcftest17 proto c
 jcftest18 proto c


;--- CStr(): macro function to simplify defining a string

CStr macro pszText:VARARG
local szText
.const
szText db pszText,0
.code
exitm <offset szText>
endm
 .data
  buffer db 20 dup (0)
 .data?
 Argc dd ?
 Argv db ?
 CmdL LPSTR ?

.CODE

_start:



Mymain  proc
    invoke jcftest17
    invoke printf,CStr("%d",10),eax
    invoke jcftest18
    invoke printf,CStr("%d",10),eax
ret

Mymain endp
  invoke Mymain
  invoke ExitProcess, NULL

    end _start


And this is my batch file for compiling

Code: [Select]

@setlocal
@ECHO OFF
@SET LIB=\jwasm\wininc\lib;\jwasm\samples\jcfuller
@SET PATH=C:\jwasm;C:\jwasm\jwlink;c:\jwasm\wininc\lib;c:\jwasm\wininc;%PATH%
@REM add more libraries below
@SET LIBS=LIBRARY kernel32.lib, msvcrt.lib, libjcflib.a

jwasm  %1.asm
jwlink  name %1.exe file %1.obj %LIBS%

endlocal


[SteveA]

Okay..., with some advice from japheth,
I was able to narrow down what the problem might be.
He could see that the "calling convention" was the source of the problem.

In your sample, it looks like you have specified that as C [ansi],

;my c functions
 jcftest17 proto c
 jcftest18 proto c

(which any C programmer might consider as standard).
However, I needed to change that to "_stdcall".

In VC, it was relatively easy, I just needed to set a switch, (once I found it).
I have not found such a switch in Lcc.
As a result, when using Lcc, I need to specify "_stdcall" in the code.

In either case, it compiles and links now without errors.