BASIC for DexOS?
For some time I've wanted to write a compiler or interpreter of a language in x86 ASM. With the knowledge I've gained of the language and the x86 hardware over the recent year, I think I am more capable of doing more in this field. I was thinking, since Solidus was working on a C compiler & library for DexOS, I think we should also have a BASIC interpreter/compiler. Don't get me wrong, I like the idea of ASM being the "de facto" language of DexOS, however I have recognized there are a lot of people in the QBASIC community who are still into programming old-school DOS games and such. What I'm saying is we might be able to pull some of those people into the DexOS community, and possibly get a bigger fan/user base. As far as how the BASIC interpreter/compiler would be layed out, I think we should set it up similar to QBasic or the like, that way when people port programs they won't have too much trouble in doing so. I think we should name it either "DexBASIC" or "BASIC4U" if we get the project started. I'm gonna try to sit down with a pen and paper and come up with a good (hopefully generic) parser design first, and then get to work on a simple parsing algorithm along with a simple, prototype interpreter itself. My theory with this is you take baby steps so you don't get overwhelmed in the beginning, but big enough steps that you get something done. :D After the parser/interpreter is done, I'll have to look into how I can code the compiler itself. What we could do it set it up so that it automatically creates the DEXecutables without creating an object file first, unless we want a generic-linker which - if you are reading this and are still working on the project, Solidus - can also use for his C compiler sort of like GCC and FreeBasic both use LD as the linker. I know my idea's far out there, and I'm sorry if I make very little sense (I just cracked myself in the back of the head with a wooden nunchaku - no joke). I just want to know the word of the people. :!:

I had started converting over a basic interpreter. I liked the Phraser and the math sections were nice. The rest was convoluted, most probably because of early cpu's and small memory. If you would like a copy of what I have you are more then welcome to it.

That'd be great! Question, though - how can DEX programs accept arguments? ie A:\ >BASIC4U helloworld.bas

I'm still working on the fasm macro layer for BASIC, I'm probably going to write a simple pre-processor for it to handle math/etc. I'm in finals week, so it'll take a bit of time to get rolling again.

Basic for DexOS is a cool project 8), and roboman and tonymac, has done some great work, maybe you could work together or swop notes. Anyway here you find some of the work on a basic for DexOS http://dex4u.com/basic If you look in basic.zip you will find a demo of Getting CLI Params, using this built in function call [GetParams] This returns a pointer to the CLI in esi, DexOS add a zero to the end of the cli so you know where the last char is etc. Also you should look at macro as there a cool demo of how to make a simple basic compiler in the Qbasic.zip. Hope this helps. Regards Dex. PS: Theres more example if you need them let me know.

Question, though - how can DEX programs accept arguments? ie A: >BASIC4U helloworld.bas That should be fine. In FreeBASIC it would be fbc helloworld.bas Here is a list of the basic (pun intended) functions found in QBASIC (for some reason it does not appear correctly in firefox) you can click on the names for more information. FreeBASIC also has a list here.

The True Beauty of ASM...
My dear friends, I think I have solved our "hard-to-write" compiler problem. What we could do, I think is take each of the generic labels in the interpreter that are jumped to which preform strings of commands in ASM, and copy those actual commands via a pointer and REP MOVSB (or something like that) into the file itself so we don't have to write each individual byte down for the routine! :D

I actually have a made a game using some BASIC marcos I wrote. I'll probably post it when the FASM forums come back up. rhyno_dagreat could you write an example of what you are talking about? You might have seen this allready. We could probably use your method, macros or both 8) macro PRINT String{ local .Done local .a mov esi, .a call [PrintString] jmp .Done .a db String,13,0 .Done: }

rCX, if you've ever looked at the MiniDOS bootloader, you notice it moves all of the code to the upper area of memory. What I mean is moving set-code into a variable array to be written to a file. I't's 1 AM here right now, so I'm about to go to bed, but ASAP I will write an actual example of what I mean. It's an easy concept. :D

http://home.comcast.net/~dexos/tinyb.zip It's based on tiny basic, it was writen for the 8080 then ported over to the 8086, but a lot of old stuff was left, then I started to make a bigger mess of it :) Some of the odd stuff is because of the 8080 cpu and some of the other is because the computers it was being writen for didn't have an os yet and mostly only had 2k or 4k of ram.....

The macros idea make me think of sort of an "inline BASIC". :lol: Here's a short example of what I mean in high-level pseudo-code: -Parse code file -Compare string parsed with "PRINT " -If PRINT was found, then move the address of the string to be printed into register ESI, and move those bytes into the array. -Load address of a print function into EBX -Copy bytes of that function into an array to be stored in the dexecutable. -Store the array on disk as the program file (make sure headers are included and respective variable addresses change if needed). That's a simple example, but it should work. I'm gonna give it a test run in FreeBASIC (booooo I know ;-D) with pointers to see if it works on the high-level. It should work on the low level easily if it does on the high level.

I'm working on a pre-processor for MacroBasic, I'm hoping to enable basic-style math declarations and remove any system-dependant code from the user program. This will also make all code compatible from dex release to dex release, as long as MacroBasic is up to date for the recompile. My reservation is my crappy file handling abilities. I would ask that after proof of concept someone rewrite all my file handling routines so as to make it more useful (I'm going to stick the whole file in memory, then write the whole file back, sucking down a lot of RAM) To alleviate this, I may take an approach similar to Java and stick all the functions and procedures in their own files and include them in the ASM source. Messy, but it will reduce the memory footprint. Future goal is to add an option for compiling a library, so the user doesn't need to know a lot about the gritty details, just declare it's a library, write the routines, compile it.

Look forwards to testing it .