Compiler memory problem

[RyanKelly]

I don't really know how BC.exe parses a source file, and I don't know the details of the p-code used by qb.exe, but I've noticed that in the quick save format, each reference to an integer variable increases the file size by 8 bytes, and a single string declaration takes about 20. If the these three transforms on the source code are at all akin to each other, a dozen references to a variable could easily take up 100 bytes.

[markar]

I've done a few tests - pulling out an unused DECLARE statement saved over 200 bytes of workspace. Pulling out a constant saved different amounts, but usually around 40 bytes. So this explains why breaking routines into smaller, more modular, chunks made the memory problem worse. Converting magic numbers to constants also exacerbated the problem.

How wonderful - a compiler that kicks you in the teeth for following good coding practices.

[Anonymous]

yeah, you really realy should start taking steps to port this to fb. you and your sanity will thank you later.

[markar]

yeah, you really realy should start taking steps to port this to fb. you and your sanity will thank you later.

I definitely would, but I don't have any way to ease into it. I've got about 30 programs and libraries that are all centered around creating and using these ISAM tables. So I would first need to figure out how to compile and use some database library to replace all my ISAM calls. Then I would need to replace all of my programs at once, rather than easing into things one program at a time. That is, unless someone has cracked the ISAM files and written a library to read them. I'm not holding my breath.

Mark

[Antoni Gual]

This guy has a C open source ISAM library.
http://www.mission-base.com/peter/source/

It should be easy to translate the headers into FB

[Moneo]

Mark,

I received the email with a copy of your code. Like I said in my email reply, the program uses ON ERROR, which will drastically increase the program's size at compile time. You should make an effort to remove ALL the ON ERROR's, so that you don't need to set a switch to the compiler about using ON ERROR's.

Regarding converting this and your other programs to Freebasic, in my opinion, this may "sound" good, but would be a tremendous conversion and re-testing effort, therefore, I don't advise it. If you'd like, I can give you specific areas in your program that would require re-write.

And, I'm just talking about converting the general code of the program. Converting, simulating, or substituting ISAM is another monster task.

ISAM was introduced on the IBM System/360 in the early 1960's. It may have been carried over to future generations of these IBM computers, like the 370 and 390, I don't know.

About 1990, when Microsoft PDS came out offering ISAM, I obtained a copy from a dealer for my evaluation. The ISAM in PDS does not look anything like the IBM version that I had worked on --- just the ISAM name is the same.

I checked out the site mentioned by Antoni, and it says: "PBL ISAM - an open source ISAM file implementation." Wonderful. An implementation of which ISAM, the latest from IBM or the latest from Microsoft PDS? Assuming you got very lucky and the implementation is compatible with PDS; are all the I/O command compatible, and are the files themselves compatible?

My advice again, stay away from these ISAM considerations. This, of course, eliminates the Freebasic alternative, since FB does not support ISAM.

Back to your original problem and immediate concern: compilation under PDS. In order to get rid of the ON ERROR's, you may need to resort to some assembler-like code. There are people on this forum well-versed in this type of coding.

If you have the time, energy, and money to invest in converting your system to another language and access method, then you should carefully weigh the alternatives.

Good luck.
*****

[markar]

This guy has a C open source ISAM library.
http://www.mission-base.com/peter/source/

It should be easy to translate the headers into FB

That's very interesting. I'll take a look at it. Since ISAM is kind of a generic name for a b-tree database, I don't have much hope that this library will be able to read and write database files compatible with the old QuickBasic code. I would need that level of compatibility to be able to rewrite my programs one at a time.

If I can't find binary compatibility, it probably makes more sense to rewrite my database code with some SQL compatible library instead of sticking with ISAM.

Mark

[markar]

I tried Moneo's suggestion and removed my ON ERROR RESUME NEXT lines, which I used in various places to test for missing files. Then I removed both the compiler flag /E for ON ERROR support and the flag /X for RESUME NEXT support.

Removing /E didn't make any difference, but removing /X gave me over 11,000 bytes, almost a quarter of the work space. Since I've already determined that a 1000 line routine of moderate complexity uses about 1500 bytes of compiler workspace, this should give me enough room to keep working for quite a while.

I still need to go back and code some replacement tests for the ERROR checks that I removed for this test. And I have to verify that I can link with libraries compiled with the error flags (or remove ON ERROR in each library).

I also have to agree with his advice about porting to FB. Unless the port is extremely straightforward (and my database usage makes this unlikely), I've got to treat it like any major porting task. If I'm going to do that much work, both coding and testing, why not bring it up out of the stone age and use a real database? Most of the work in this particular program is procedural, but most of my other programs revolve around data transformations.

Anyway, thank you everyone for your suggestions and willingness to help,

Mark