Basic compiler for Linux?

[farmkid]

In my work, I have begun using a program my boss wrote 20+ years ago as part of his dissertation (I'm a scientist doing some genomics work). It's not a very complicated program; it's a clustering algorithm to group data. It's rather old, but it works fine for what we want it to do. However, he originally wrote it in BASIC and it runs in DOS. That's not a big problem either, except that because it's running in DOS, it runs out of memory very quickly. When I have a large dataset, I have to split it into a few smaller chunks in order to process the data. I'm pretty sure I can get the source code, so I'm thinking that if I could recompile it to run in Linux I could process all the data without having to split it up and run each part separately.

I'm not a programmer, so I have no idea whether this is even possible. A quick Google search finds several BASIC compilers, but based on the names, they seem to work with different flavors of BASIC. As I remember from my days playing with BASIC as a kid I remember there being many different kinds, but I don't know how compatible they are with each other. So, my question is whether or not this is something worth pursuing. I realize no one can give me a definitive answer, but I thought I would ask here before spending hours to days figuring out how to do it only to find it's going to be a major project and not worth the time. I don't really want to or have the time to rewrite the code. Does anyone know enough about BASIC and the various compilers out there to give me an idea how successful I might be and how long such an effort might take, or how much work might be involved?

 

[Robert Maxwell]

It would be nice to know what flavor of BASIC the original program was written in. Without knowing that, it's impossible to say what Linux BASIC interpreters (if any) would be able to run it, and with what degree of modification.

 

[Santaman]

Hmm, you could try and run it via dosbox on a Linux rig, might solve your problems.

 

[Robert Maxwell]

That's actually a great idea, as long as performance isn't a huge concern.

 

[Santaman]

The OP said the program was about 20 years old so right about in the 286 -486 era, any current PC should be able to run the most demanding piece of software from that era with extreme ease..

 

[farmkid]

Would running it is dosbox solve the memory problem? The only issue I have is that when running it in DOS it runs out of memory very quickly, necessitating the data be split up into smaller pieces. As for performance, I don't think that will be a problem. When he first wrote it, he was running it on a 286, and it took long enough that he would start it and then go find a snack or something. Now, however, one hardly has time to blink, in spite of the datasets being much larger.

As for the version of DOS it's written in, I have no idea. I'm not sure my boss would even remember after this long. Are the different versions different enough that code written for one version won't work with compilers for any other version? I'm not sure if I made it clear earlier, but modification of the code really isn't an option, unless it's very minor. I don't have the time to relearn BASIC and dig through all the code fixing it up to work with a different version. To do so would be more costly in time and hassle than just dealing with the split data files.

I'm not yet at the point where I'm finding a specific compiler for it. I'm just trying to figure out the likelihood I could do it without much trouble or if it's more likely to be a big headache.

 

[Santaman]

The maximum amount of RAM possible in DosBox is 64Mb which is 4 times the entire amount of RAM a 80286 machine supports. (286's are 16 bit CPU's with a 24bit address bus)
I assume thats enough to make your program run quite well.

 

[Robert Maxwell]

Santaman is right. Also, the version of DOS is irrelevant--the BASIC interpreter is what's important. You're obviously running it today. What BASIC interpreter are you using?

I would still recommend you try the DOSBox solution first. That would be the path of least resistance.

 

[Jadzia]

It's unlikely to be running out of RAM.

It's more likely that the BASIC compiler creates an executable that is compatible with the 286 memory architecture, whereby it's allocating one fixed 64kB block that is expected to be held entirely in conventional memory.

64kB is all you get with 16-bit memory addressing.

 

[Robert Maxwell]

That's part of why I was asking about the BASIC interpreter. If it has hard limits built into it (by design tradeoff) then DOSBox also won't help and he'll need a bona fide replacement interpreter/compiler. That is all assuming the program isn't doing direct memory management with PEEK/POKE, in which case it is probably not (easily) fixable.

 

[farmkid]

I'm not sure what BASIC interpreter (or compiler? is that the same thing?) it is. I don't actually have the program yet. My boss showed me how to use it last Friday, but he hasn't actually given me the program yet. I don't remember from my childhood (the last time I messed around with BASIC), but BASIC programs compiled into executable files, not run as scripts, right? In that case, am I right in thinking that all I need to do is get the source code and recompile it using a newer compiler?

The data files really aren't that big. Frankly, I was quite surprised when I saw that the program ran out of memory. They're just text files that get up to maybe 150K or so.

 

[Lindley]

The program is probably being built as a 16-bit executable. Most likely, compiling it as a 32- or 64-bit executable will solve the limitation. (It isn't running out of memory per se, just address space.)

 

[Robert Maxwell]

Every BASIC I've ever used (in the DOS era) had you run a file (usually *.BAS) through an interpreter, e.g. "gwbasic myprog.bas", with "gwbasic" being the interpreter. I think later versions of BASIC allowed you to compile to bytecode, but then you wouldn't necessarily have the source.

It's whatever you run the source code through that is your "interpeter." The source code itself cannot be run, obviously. It must either be compiled or sent to an interpreter. Either way, in order to identify your flavor of BASIC I'd need to know what that program is!

 

[Jadzia]

They can be compiled to native binaries, as Visual Basic does this.

Most don't seem interested in making decent compilers for basic... for some reason.

What tends to be made are fake compilers, which simply bundle the interpreter and the source code into an executable wrapper.

This is what QuickBasic did, (Microsoft's free basic language for DOS).

 

[Robert Maxwell]

BASIC sucks, that's why no one wants to make compilers for it.

Hell, BASIC gave interpreted languages a bad name that persists to this day.

 

[Jadzia]

I love Basic. It's just that each/every dialect of it seems to have it's quirks. And it's those quirks, together with the absence of a decent compiler, that have given the language a bad name, imo.

 

[Robert Maxwell]

BASIC came before C, so it doesn't have most of the characteristics we've come to associate with C-style languages.

I find it functional but pretty brain-damaged, overall. Nevertheless, I code in MUMPS every day which is like a dialect of BASIC on hard drugs.

 

[farmkid]

I don't yet know if the program is run through an interpreter or is something like Jadzia says, an intpreter and the source code "bundled into an executable wrapper". I've asked my boss for it, but I'm still waiting.

The data files are essentially a spreadsheet with the data in columns and rows. The program sorts the rows based on similarity of the data in the columns to group samples based on similarity using an algorithm in the original code. It can also sort the columns based on the data in the rows to find similar patterns. These data files come from Excel, and it occurs to me that this is something that Excel might be able to just as well, if not better, with a properly developed macro. As I understand it, the VBA available in Excel for more complex macros is derived from the BASIC of old, right? Is it still similar enough that VBA could run the BASIC code, or could the BASIC code be adapted for VBA in Excel?

 

[Robert Maxwell]

VBA looks nothing like the BASIC of the DOS era. The code will not be the least bit portable.

However, you should be able to read the original BASIC code and divine its purpose without too much difficulty. BASIC is kind of a monstrous language but I've never found it particularly hard to read.

 

[sojourner]

The data files are essentially a spreadsheet with the data in columns and rows. The program sorts the rows based on similarity of the data in the columns to group samples based on similarity using an algorithm in the original code. It can also sort the columns based on the data in the rows to find similar patterns. These data files come from Excel, and it occurs to me that this is something that Excel might be able to just as well, if not better, with a properly developed macro. As I understand it, the VBA available in Excel for more complex macros is derived from the BASIC of old, right? Is it still similar enough that VBA could run the BASIC code, or could the BASIC code be adapted for VBA in Excel?

LOL, before I got to your 3rd sentence I was thinking, "heck, that can be done in Excel pretty damn easily". Don't waste your time trying to save an old program. Make a spreadsheet that can do the same function. -Bonus, you'll be able to make shiney charts of the data.