What's opinion on routine use of $SEGMENT in MAIN's?

[Mike Luther]

From a practical usage standpoint, I'd like to hear what the users
here think about routine use of $SEGMENT breaks in MAIN moudules.

I've done as good a job as I can do at breakapart of code work as
seems practical for my mix of PBU's and common source library work.
But with almost a dozen major executables now way up in the 25,000
line range, I'm reaching the point where there is just so much that
has to go on in MAIN, that it just isn't coherent for maintenance
work planning to keep trying to chop up what really is the MAIN logic
of the executable, just to keep MAIN down below 64K.

Yes, I realize that an overview of the whole MAIN module does in fact
lead to better places where a $SEGMENT can be placed, among perhaps
a number of 'proper' places that it might be placed.

But a real nagging question, after seeing what subtle shifts of a
$SEGMENT that shouldn't be needed below 64K, but are, to just get things
to run or stabilize a project, is; what's the practical experience of
some of the crew here in deliberately using them to extend what needs
to be done in MAIN beyond 64K?

Of course, from a tool design standpoint, it shouldn't make a differece
if you use the technique as it is supposed to be used! And there are
those who would be critical of ever trying to do things in large
executables as opposed to skaty-eight tiny modules that all do this
and that. What I want to learn about is the experience of those
here that are actually using the $SEGMENT technique deliberately to
extend the capability of a > 64K MAIN design. That as well as any
official comments on things that may help to assist me in making the
decisions on how and where to place such a deliberate fence between
pastures here!

No guarantees needed, just thoughts - please.

For example; is it better design to place a $SEGMENT between the
major setup, dimensioning and include code, than, for example, just
ahead of all the error trap routines at the bottom of the MAIN?
If you, as I do, for example, coddle all by BTRIEVE work in a major
block of 'standardized' routines, should I contemplate the use of
a $SEGMENT immediately before or after that major block?

Why has this surfaced?

An in-practice position as to security of access for program operations
is now being thrust upon us. Just the additional level of in-program
security and logging checks and trace traps now being 'required' or
soon to be so in the near future, is markedly adding to what I'm being
forced to consider for 'normal' operations here.

Help me contemplate the future of who iz, why, when and where?

Thanks.


------------------
Mike Luther
[email protected]

[Lance Edmonds]

In all my experience with PB/DOS (many years and many large programs suites written), getting each segment as close as possible to the 64K mark works just peachy, and I've NEVER EVER had any problems (that were fixed by reducing a segment size) with any of my programs containing anything up to <U>16</U> segments.

Others have commented on the problems you allude to, but I've not seen any code that has shown up such a problem. Thus far, all such discussions are nothing more than anecdotes.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

Thanks Lance ...

This is exactly the kind of practical experience I'm looking for.
Frankly, I can't see any kind of logical reason why there should be
any difference at all between a segment which is the result of a
PBU and one produced by $SEGMENT in the code body.

What you are also saying in your comment is that the use of the
$SEGMENT technique in MAIN and getting it as close to the 64K max
size per each is actually the way it probably works out in practice!
We code until we reach the limit. Then we choose an apparently
applicable place to try for the first such $SEGMENT mark. We put
'im in and go about our business.

Any else care to note long term use of this technique in practice
with distributed code over a period of time?

Thanks


------------------
Mike Luther
[email protected]

[Jerry Fielden]

I'm not here to make a comment about $SEGMENT, since I only had to
use it only once and it did solve my problems. Since the subject was
was brought up, I read my 3.0 manual to refresh my memory. It says not to
locate it in structured blocks like For/Next, DO/Loop, While/Wend
or an If Block. Now it didn't mention anything about Select Case. I'm
thinking that is a stuctured block also. Should it be included with the
rest that is listed?

------------------


[This message has been edited by Jerry Fielden (edited August 27, 2002).]

[Michael Mattias]

Just put $SEGMENT statements anywhere except inside a procedure.

I have never noticed any difference in speed - or in anything else except compilable program size - from the use of $SEGMENT (although as I understand it, there are some optimizations done if all referenced code is within one segment). It's as though the $SEGMENT statement doesn't exist, except you don't run out of space when compiling or get seemingly random data corruption "near the edges".

MCM

[Tom Kennedy]

I've been using PB/DOS since I upgraded from Turbo Basic sometime
in the early 90's, and have worked up to 11 segments (looked at
source for a larger program that's been in use for about 8 years,
I didn't remember) with no noticable effect. I put them where
it's convenient, close to 64k, outside of loops, procedures,
subs, etc. and haven't had to give them any thought in years.
I'm sure they slow things down a trivial amount , but neither I
nor anyone else has ever noticed.

Tom


------------------

[Mike Luther]

Thanks Tom, Mike and Lance, again, for the earlier comments ..

And Jerry, I think you got your answer from Mike M, just fine.

My first deliberate venture into this is going forward. The first
romp looks like it will add about 16K over the right at 64K that was
there in the original case. Everything else done and tested, it'll
likely get released for wider test late this week. In my case, all
the Btrieve mass manipulation code is always located just above the
error trap routines. master keyboard I/O and final close/down - exit
area of the whole suite at the end of the MAIN coding.

Since this will substantially impact, in the coming weeks, about a
dozen other executables. all designed similarly, the chosen placement
is important in concept for future use to me.

I'm still fishing here in the forum, for thoughts as to whether it might
be 'conceptually better' to plan this long term strategy on a generic
deliberate split up at the top of main, or at the bottom, in general.
Again, this is *NOT* to stir up why $SEGMENT does this or that. And
Mike M's comment on internal optimization if all the referenced code
is inside a demarked $SEGMENT is exactly the kind of thing I was fishing
for here.

The idea is to try to create a top down policy strategy in starting to
use this technique which might possibly have less chance of an oblique
failure later on, even years later for somebody other than me who might
see or have to work with this stuff. The following contains an anectotal
thread - it has no rhyme or reason why it should be bere, so forget it!
But it also illustrates part of the reasoning process as to why I want
other opinions on how to generalize the design of this technique. That
knowing full well how kids all flock to the latest trend, even though
like this 63 year old kid I'll be working with a new toy ..



Let's suppose that we have made the master decision that we will place
all declarations and setup code at the top of a program. At the top of the
commonly thought to be start of execution we always will do two other things.
We will determine anything control-wise, we need to do to establish a proper
and needed relationship to printers and other I/O channels. Here, too, we
will always create the directives for our error handler section of the code.
That's always going to be defined at the bottom of everything we do. But
not the very bottom .. just close to it.

For years now, my pager has quit going off since I did the following.
Immediately after the last dimentioning statement, which is also
underneath the ON ERROR GOTO directive. It's also under the EXIT FAR
directive which Lance got me to use so long ago and also contributed
wonderfully to my ability to sleep all night without the digital pager
going off.

[source]
' Excercise all Btrieve buffers including one more than you'll need
FOR Bfile% = 1 TO 4
CALL BT39776(IDEXDRV$, P9$, KYCAP%) ' CLRTFBUF:
CALL BT39785() ' CLRDBUF:
NEXT Bfile%
' --- This is anecdotal - but I get to sleep nights now.
MEMPACK
' ---
DEF SEG ' Reset before init
WIDTH LPRINT 132 ' Set lprint max
DEF SEG ' Reset after init
' --- Wonderful! No pages tonight!
' Body of all executable code goes below
[/source]

The above was determined by hours and hours of testing to stop much
of the unexplained where did my variable go and why. It isn't at
all needed to go into any discussion about other than to illustrate
the reason I asked the question as to a hunch about where to put the
deliberate use of $SEGMENT.

But I could contemplate a deliberate inclusion of a $SEGMENT directive
at any point in the above, or just above it, or just below it! It
just turns out that the entire code suite here may take a massive
jump in variable definitios, setup logic and included PBU's. Likely
it will, for professional reasons.

The constant use of X.509 digital certificates, biometric ID solutions,
moving target constant reference to GPS or other "Where am I?" code,
(Which has already been in my entire suite for 20 years now.. ) will
massively expand the interface operational requirements, as I see it.
In that data which will be constantly bickered about in relation to all
this mess will be needed in the entire operations suite professionally
in the very near future, I could contemplate gaining the needed space
in main by chunking in the $SEGMENT direction up at the top side of
all this.

I could attempt to place it before the ON ERROR GOTO directive. That
would keep, it would seem, all error trapping in the same $SEGMENT,
including all EXIT FAR operations from, in some cases, heavily nested
SUB's and calls. Remember, anecdotally, that includes the exact places
where variable values go nuts at times.

Placing $SEGMENT anywhere between ON ERROR GOTO with EXIT FAR, and any
of the error trap operations, means all this has to transit that $SEGMENT
you just plunked into the operation, perhaps...

Now, just between all us very pious and holy men and women whom might be
still reading here, with absolutely no specific allusions at all to
anything but pure humor here. May I go back to the opperetta "Oklahoma"
and my blessed Mother singing to me as a kid?

"What you gonna do when he talks that way .. spit in his eye?"



Sometimes I think that they should have used words that spelled HIPPO
instead of HIPAA here in the medical world in the USA, grin. So what
would you do if you were Mikey Dog in relation to a deliberate use of
$SEGMENT and where to generically place 'im?




------------------
Mike Luther
[email protected]

[Barry Erick]

When I ported over Quick Pack Pro for Crescent to PowerBASIC, I
had to add segments to all of the pbl libraries as assembly code
and the libraries could be used in any mix and could easily go
over 64k.
I did sort out routines according to the type and keep those
together in the same segment. While the demo's did not need them,
any actual program did. I also gave them unique names that
a user would be unlikely to pick so I did not touch their segments
--Barry


------------------