Is there any interest in this? - BASIC compiler for FreeBSD

Eponasoft

Eponasoft

Wasn't sure if this was the right subforum for this, but it didn't seem to fit anywhere else. Is there anyone out there who would be interested in a BASIC compiler designed specifically for FreeBSD? I've yet to run into any proper BASIC compilers for FreeBSD; the only one I've seen come close is FreeBASIC (Linux), and it doesn't build in FreeBSD due to library differences...and of course, there's always the spattering of BASIC interpreters that can be built, but at the end of the day, they're just interpreters. I've searched high and low for this and have come back empty-handed every time. So, I decided to fill this apparent void myself. I had made two attempts prior but fell short because compilers aren't really my forte, but this time, I reckon I'm going in the right direction. Third time's a charm, I guess. :) But anyways, it would be nice to know if there's any interest in this. Opinions? Thoughts? All comments welcome. :D
 
edit: I can't read.

Anyway - if you find it interesting, I'd suggest going ahead even if there's no obvious userbase; it sounds like it could be a fun project. :)
 
Well, I'm certainly going to follow through with the project; I've already invested quite a bit of time in it getting it almost to the point of being able to actually compile. Right now I'm starting to add in graphics functions using Xlib. This most certainly won't be able to compile most QBasic source code (the dialect in my compiler is a bit different than QBasic's), but anyone with some BASIC experience should be able to pick it up with ease. Honestly, for the most part, if you've used one BASIC, you can use them all...well alright, except maybe VB.net. :)

EDIT: The compiler right now functions as an interpreter rather than an actual compiler. It will eventually generate actual binaries. Anyways, I have just added the code for creating a window; even though this is seemingly trivial, it's the basis for all graphical functions to come. I have a long way to go on this, but so far it's looking pretty decent. The important part is that so far, it's pretty efficient...it'll never be on-par with gcc but it will at least be a decent BASIC offering and, of course, the only one exclusively for BSD. :)
 
Eponasoft said:
The important part is that so far, it's pretty efficient...it'll never be on-par with gcc but it will at least be a decent BASIC offering and, of course, the only one exclusively for BSD. :)
Click to expand...

Creating compiler for the specific OS or even for a specific
architecture is terrible idea. It will make very hard if not impossible to debug it. Also early optimization is the quickest way to crappy software (Donald Knuth).

I will be perfectly honest with you. Your whole idea sounds like a poor school project. You might even get A for the course but I personally would not let you thinker with compiler on my machines.

For an example of good work on a compiler you should look into the recent magnificent work on Portable C Compiler (PCC) which will hopefully in near future replace buggy GCC on *BSD systems.

I would personally do lots of investigation into already existing
Basic compilers before writing a single code. Is there are any compiler which in your expert opinion could be used as a foundation for the new one (either just ideas or possibly some
already existing code). Then start moving by adding code based on your new revolutionary ideas about the theory of compilers and their implementation to Basic language compiler. I will be eagerly awaiting results of your work in couple of years and maybe even show up for your Ph.D. dissertation defense.

Most Kind Regards,
OKO
 
It's not a school project; I've been a programmer since 1984 and have written thousands of programs, including many commercial applications. BASIC was my first language back then, on a Commodore 64, so it's always been one of my favorite languages. My compiler does have roots in another BASIC...the expression parser is based in part on the work of Malcom Mclean, who wrote a very straightforward interpreter called Minibasic a number of years ago. I would have opted to convert FreeBASIC for BSD, but the codebase has become increasingly cryptic over the past couple of years (not to mention very poorly commented), and they have been wrestling with the idea of turning it into a GCC frontend for some time now (apparently it already has a C emitter) so in either case it would be a wasted effort.

I don't understand why people believe that writing for a specific platform makes things "hard, if not impossible, to debug" when actually, the inverse is the truth. When you concentrate on a specific platform, not only can you gain a deeper understanding of that platform, allowing you to do things you simply cannot do when writing "portable" code, but you also cater specifically to the users of that platform. I have no need for early optimizations; efficient code can be written from the start if you know how to do it ahead of time. It's much, much easier to keep the floor clean if you don't dirty it in the first place, know what I mean? :)

I appreciate your time in stating your opinions, but please do realize that I completely understand what I'm doing and have a clear-cut set of goals. I just don't always express things as clearly as I can because I usually post tired. :)
 
Yeah, there's always interest in something like a basic compiler no matter what the platform. Some of us just hate or don't get on with C. I for one am familiar with basic, fortran, pascal and
some very basic assembler - not including a couple of scripting languages. If it works it will be appreciated.


<<<
Eponasoft
Junior Member Join Date: Nov 2008
Posts: 14
Thanks: 0
Thanked 0 Times in 0 Posts

Is there any interest in this? - BASIC compiler for FreeBSD
Wasn't sure if this was the right subforum for this, but it didn't seem to fit anywhere else. Is there anyone out there who would be interested in a BASIC compiler designed specifically for FreeBSD? I've yet to run into any proper BASIC compilers for FreeBSD; the only one I've seen come close is FreeBASIC (Linux), and it doesn't build in FreeBSD due to library differences...and of course, there's always the spattering of BASIC interpreters that can be built, but at the end of the day, they're just interpreters. I've searched high and low for this and have come back empty-handed every time. So, I decided to fill this apparent void myself. I had made two attempts prior but fell short because compilers aren't really my forte, but this time, I reckon I'm going in the right direction. Third time's a charm, I guess. But anyways, it would be nice to know if there's any interest in this. Opinions? Thoughts? All comments welcome.
>>>
 
Well, work presses on. For the hell of it, I decided to bring the code into Windows and see if I could get it to compile under mingw. Ran into naming problems...since I'm using sleep() for the SLEEP function, I have to have a different version written for Windows; to use Sleep() in Windows (yep, they capitalized it), you have to include windows.h which completely poisons your program with tons of unneeded labels. Needless to say, it would not compile, and won't compile without a lot of variable and function renaming. So I'm not even going to bother with that noise.

Oh, I should note that it is likely to compile in any form of Linux that has a proper gcc and X11 libraries and headers installed. I will test this theory tonight if I get the chance; as far as I can tell, the only difference is what libraries to link. Linux obviously won't need libm (since math.h is linked with libc) but it's needed here.
 
Okay, I installed an older copy of Debian that I had laying around doing nothing, and after installing all of the dev libs and tools (since it doesn't install them by default...silly, silly people), I managed to get it to compile in Linux. However, it is still requiring me to link against libm, so it looks like any advantages of NOT using libm have just flown out the window. :) It should perform the same in Linux as it does in BSD. However, as BSD is the intended target, I will always make sure, first and foremost, that it runs here. It should always compile and run in Linux without issue though.

I set up a website for this the other day but left it unlinked here. I suppose I can give out the URL now.

http://www.bsdbasic.com/

Not much there just yet, but the Syntax page will contain up-to-date info on the progress of the dialect and compiler.

By the way, I have no intentions of making bsdBASIC self-hosting. Though it would most certainly be capable of this one day, I don't plan on making it a goal. However, the preprocessor will likely be written in bsdBASIC, so at least a part of it will be written in itself. :)

Oh by the way, it should also compile with DJGPP, as unistd.h in DJGPP contains all the functions bsdBASIC requires. The graphics and sound routines, however, will not be compatible with bsdBASIC and would have to be wrapped to another library.
 
Why not? Another tool would be great. Want to be famous? Write a compiler that will cross compile Visual Basic 6 code to freeBSD.
 
I have always wanted to make a VB6 cross-compiler. Maybe after this I will. I don't know how well that will work though. Simple, intrinsic-only apps in VB6 would be rather easy to make a compiler for, but once you start digging into the API, things get messy. Then, there's support for the Variant type...that would be quite a mess to add (I've yet to find a real use for Variant though...it seems to be mainly for lazy coders who can't figure out what data type to use). We'll see when/if the time comes. :)
 
Ahh man, it requires X libs :(

Looks like it won't be getting installed on my dev server.

I do have a FreeBSD workstation, but it usually isn't on. Looks like I'll have to install there.
 
My first stabs at programming were tinkering with QBasic back in 94. Since then I've tried to learn a few languages on my own, but the only thing I've really gotten anywhere with is the shell.

It would be awesome to have an actual Basic compiler (or even a currently maintained interpreter) available for those times when I want to tinker around with programming.

I'll keep an eye on this project -it beat the hell out of trying to figure out perl. �e
 
cajunman4life said:
Ahh man, it requires X libs :(

Looks like it won't be getting installed on my dev server.

I do have a FreeBSD workstation, but it usually isn't on. Looks like I'll have to install there.
Click to expand...
I'm toying with the granularity of the compiler; if the GRAPHICS statement isn't used, I can always just prevent the X libs from being linked in, therefore allowing an app to run without X. Also, if you need graphics routines outside of X, you can always link in another library, such as svgalib...might be better that way anyways.
 
After some careful consideration, I am deciding to axe the X idea and go with svgalib. Of course, this only applies if graphics are required. I will add an option for X, but it will not be required for graphics. In addition, I will later on implement GUI toolkit support right into the compiler. Further down the line, I will also implement a visual builder to sweeten the deal even more. For now though, I will dump out the Xlib requirement and link in svgalib instead for the test bed, and add it to the linker ruleset once all the functions are finished. In any event, using svgalib will make it closer to old BASICs anyways. However, if there are any more suggestions for how I should proceed into the realm of graphics handling, I'm all ears...err eyes. :) Naturally, I could opt to axe graphics support altogether, but that just kills half the fun of BASIC. :D
 
Wow, svgalib is really, really picky...like "permission hell" kind of picky. But I guess this is the price you pay for this kind of power.

Anyways, I've planned out the method I'll use to ensure high granularity. This is also where other people will eventually be able to contribute if they want to. Each BASIC statement, keyword, function, etc. will have a "stub" file that contains the actual code that goes into the compiled program, plus other details like linker options and parser code. Since these files will be plain text, a user of the compiler will be able to modify these to suit their needs. For example, here's how the GRAPHICS statement will be handled:

Code: 
[linker]
-lvgagl -lvga

[header]
#include <vga.h>
char graphicsmode; /* flag to indicate if graphics mode is enabled */
int func_graphics(int mode);

[source]
/* GRAPHICS statement */
int func_graphics(int mode)
{
  if (graphicsmode == 0)
  {
    vga_init(); /* if a graphics mode is already set, no need to do this again */
    graphicsmode = 1;
  }
  if (!vga_setmode(mode))
  {
    return ERR_ILLEGALFUNCCALL;
  } else {
    return 0;
  }
}
and so on and so forth. Yes, my code isn't the prettiest out there and I should rewrite this function just a little bit but it functions and that's what's important right now. :) In any event, the user will be able to modify this file to suit their own needs if they want without ever having to touch the compiler internals. And since it not only controls the injected code but also linker options, granularity is kept very high without need for binary stripping.
 
I don't know squat about building a compiler, but I know that many back-ends exist out there (like C-- and llvm). Are you rolling your own or using something like this?
 
No, bsdBASIC is written from the ground up with a C emitter for gcc. So...rolling my own. :) I'm something of a control freak and don't like to spend time in learning someone else's system that may not do the job in the end.
 
Zombie thread! :)

With all the free time I've had lately, I've been able to do some more work to bsdBASIC. The svgalib code was cut out and replaced with SDL. I was able to rapidly add all kinds of graphical routines after that, thanks to SDL_gfx and SDL_image. Sound routines will be added next, courtesy of SDL_sound and SDL_mixer. Graphical font support has been added thanks to SDL_ttf. The core has been completed for some time now; I just never had a chance to add the really fun stuff. :) svgalib was a real pain in the tail and grx didn't make it any easier, so both are now history.

There are two ways of setting up a graphics screen in bsdBASIC. The easiest way is the GRAPHICS keyword. It takes a single numeric argument, indicating the screen number. This is based on the VBE 2.0 standard list of modes. The other method is the GRAPHICRES keyword, which takes the X and Y resolution in pixels, the bits per pixel, and a flags field (for toggling fullscreen, etc). GRAPHICS sets fullscreen by default. Once you have a graphics screen up, you can use all the normal primitives, like PSET, LINE, etc. but also new functions like IMAGE and SPRITE. The classic GET and PUT will be added eventually but right now it's not a priority. Graphics have always been the most fun part of BASIC in general and I wanted to make sure bsdBASIC had its share of niceties for that. :)

For the moment, the C emitter is on hold, pending a total rewrite. So in the meantime, the interpreter version is what is being developed. Once I am satisfied with its progress, I will retrofit it for proper compilation. A release of bsdBASIC is due very soon, perhaps by November or so, depending on various life aspects (like finding $1000 in the next two days to keep my house and my car) but yes, it will be coming out quite soon. :)
 
bsdBASIC's syntax isn't quite the same, so it wouldn't work without some modifications. I will certainly try to rewrite it to run properly though. :)
 
Well, I have prepared a rather nice package of FreeBASIC for FreeBSD, cut of the nightly svn. The only thing missing is graphics support, and that's only due to a packaging error (the next release won't be crippled in this manner).
 
You must log in or register to reply here.
Back
Top