Re: QBasic 1.1 language

On Wed, 29 Aug 2007 01:30:30 -0400, Happy Trails <nomail@xxxxxxxxxxx>
wrote:

On Tue, 28 Aug 2007 20:53:29 -0500,
ArarghMail708NOSPAM@xxxxxxxxxxxxxxxxx wrote:

Like, if you put data in COMMON, it got it's own segment.
I think NAMED common does, not sure about unamed common.

Just think of unnamed COMMON as a common section with the name NONAME,
and you'll understand it, hahaha.
Doesn't work that way.

From QuickBasic 2.0 (But works the same way for all MS 16-bit Basics):

title prefix
_CODE segment para public 'BC_CODE'
_CODE ends
CSEG segment para public 'CODESG'
CSEG ends
CODE segment para public 'CODE'
CODE ends
SHELL segment para public 'CODESG'
SHELL ends
CLEAR segment para public 'CODESG'
CLEAR ends
BC_ICN_CODE segment para public 'INIT_CODE'
BC_ICN_CODE ends
BC_IDS_CODE segment para public 'INIT_CODE'
BC_IDS_CODE ends
INIT_CODE segment para public 'INIT_CODE'
INIT_CODE ends

; DSEG must come first and not be CONST or _DATA so that other
language
; obj's do not mess with the location of DSEG
DSEG segment common 'DATASG'
DSEG ends
CONST segment para public 'CONST'
CONST ends
DATA segment para public 'DATA'
DATA ends
BC_DATA segment word public 'BC_VARS'
BC_DATA ends
named_common segment word common 'BC_VARS'
named_common ends
BC_FT segment word public 'BC_SEGS'
BC_FT ends
BC_CN segment para public 'BC_SEGS'
BC_CN ends
BC_DS segment para public 'BC_SEGS'
BC_DS ends
COMMON segment para common 'BLANK'
COMMON ends
LAST_SEGMENT segment para public 'LAST_SEGMENT'
LAST_SEGMENT ends
DGROUP group DSEG,CONST,DATA,BC_DATA,BC_FT,BC_CN,BC_DS,COMMON
end

All COMMON gets lumped into DGROUP, at least in the compiled program.

You could have many times the data space available this way.
Yes, but you still have to live with the 64k DGROUP limit, and QBX
eats 20k or so.

What do you understand "gets it's own segment" to mean?
In reference to what?

DGROUP gets is own segment.
The CODE from each source file gets is own segment.
Each dynamically allocated gets is own segment(s).
Each string pool gets is own segment.
Externally linked routines may or may not get it's own segment,
depending upon how it's compiled/assembled/whatever.

If you used far strings, I'm pretty sure you got another 64K for the
far strings; ditto COMMON. Otherwise my systems/programs weren't
really as big as they were, hahahahaha!
With PDS far strings, you can have up to, I think, 3 string sub pools
of up to 64k each. Some testing, years ago, lead me to think that.
COMMON lives in DGROUP. (See above)

There was also something funny about space allocation for structures
or whatever they were called, that let you bump up variable space as
well, (or maybe that's a different compiler).

In total I think you could "theoretically" get 4 x 64K of data space
altogether, but I never verified this.
A dynamically allocated array whose element length is a power of 2 can
occupy ALL available memory, so long as it does not exceed 32,767
elements per subscript.

For example, this little program:

DEFINT A-Z

REDIM a#(0, 0)

FOR n = 1 TO 32000
ERASE a#
PRINT n, 8# * n * n
REDIM a#(n, n)
NEXT n

In the IDE, it gets to 162, data space used 209,952 bytes.

When run compiled, it gets to 266, data space used 566,048 bytes.

That also tells you that the IDE uses up about 350K bytes of space.

Wasn't there also some oddball trick in either BC or the linker that
let you compile subs and link them as overlays? Then when they were
loaded they went in to EMS, so when they ran, they only had to be
copied from EMS to some low memory area to run. So if you had stuff
that didn't get used all the time, you did this to them. It was the
runtime equivalent of that other trick you mentioned earlier.
Yes, but are better using the overlay routines from VBDOS 1.0

There was also some bug which I merely avoided rather than solved in
the IDE when you weer adding code to a program. At some point it
would just start giving errors every time you tried to add another
line. So you'd delete some other stuff and try again. Or you'd save
and reload the whole thing - same problem.

What I'd do then is reinstated the whole thing, save it as ascii, load
it into another editor, like Wordstar or something that could handle
any size file, then add the new code I was trying to add in the irst
place. Then I'd load the newer, bigger program into QBX, and most of
the time it would just carry on as if it were the most normal thing to
do????!!!!

I once ramped one program up to over 22,000 lines of source this way.
I eventually hit other limits though that made it too much of a pain
to keep doing this, and it was too much trouble to debug this monster
because you couldn't add one line of code in the IDE without getting
hard complaints.

BTDTGTTS. Happens when I am debugging BGEN, the code generator part
of BCET. Sometimes, F6ing and doing a CLOSE and/or RESET allows me to
save the current file. Other times, it crashes the current DOS
session.

BTW, the only solution is more low DOS memory.

You also never wanted to "include" any file more than once, because if
you had 2 or more includes of the same file in the IDE, it would load
2 or more copies of the same thing into the IDE. That really ate
space up fast.
Hell, yes. That is why BCET is one single 237k + one 3.6k source
file. The big one is way WAY too big to actually compile with BC.
That is why I have a utility to split it into 13 smaller files to
compile. And some of those are pushing BCs limits.

My source files were huge because they contained all the SUBS. To
compile anything, I just split off all the SUBS into separate files,
added a line at the front of each to copy in the single humongous INC
file whether it needed it or not, and compiled each one that way.

There was a remark flag to indicate if a SUB was overlayable.

The compile .BAT and link .RSP files were built automatically, of
course, so there was no maintenance to do on the compile builder
system, no matter what software I added or changed. It only ever took
about 2 minutes to do about 200+ compiles/links on an old 486. Not
even enough time for a coffee.

That wouldn't work for me. I have too many include files, some of
which only apply to a single sub. My utility reads a flag on each sub
for function line, and copies it info the correct file. Besides, I
don't what to have to deal with 200+ object files, 200+ source files
.... 13 is enough of a headache.

Some interesting reading from the QBX help system. With a help page
selected, try searching for:

Overview of Memory Management
Using Expanded Memory

And "/Ea" & "/Nof" in the command line section.

I knew about these, but over time, had forgotten.

Me too. In fact, I moved from Singapore to Toronto a couple of years
ago, and haven't seen my PDS manuals since then. I had read those
absolutely cover to cover, including the link & lib sections, many
times in the previous 12 years, but it's getting a little hazy now.

Most of the important stuff from the manuals is buried somewhere in
the help system. Trick is finding it.
--
ArarghMail708 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.
.

Relevant Pages

  • Re: Weird bug in VS.NET 2003 IDE
    ... > From time to time, when I save my code, the IDE decides to add lines to ... > End Sub ... > End Namespace ... > the IDE adding all these lines is that the program fails to compile, ...
    (microsoft.public.vsnet.ide)
  • Re: QBasic 1.1 language
    ... I think NAMED common does, ... the IDE when you weer adding code to a program. ... The big one is way WAY too big to actually compile with BC. ... My source files were huge because they contained all the SUBS. ...
    (comp.lang.basic.misc)
  • Re: Looking for a free basic compiler for DOS
    ... mother of an ide file - and created separate source files for each SUB ... big to compile in one bc step. ... the source for all the SUBS in the same source file. ...
    (comp.lang.basic.misc)
  • Re: Very Confused: Class, Imports, ...
    ... what you need to do is compile common.vb to common.dll using the ... > I created a new file named common.vb where I created a class named common and where I ... > Public Shared Sub MyFunction01() ... > Basically all I need is to use Common functions in my aspx pages class. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Compile errors in VB6 running in VirtualPC
    ... using the "Shared Folders" functionality of VirtualPC. ... Trying to open VB6 projects would fail with "Path not found ... The VB6 IDE could now open and compile ...
    (microsoft.public.vb.com)