Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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]
    Mike Luther
    [email protected]

  • #2
    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>
    Lance
    mailto:[email protected]

    Comment


    • #3
      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]
      Mike Luther
      [email protected]

      Comment


      • #4
        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).]

        Comment


        • #5
          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

          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            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


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

            Comment


            • #7
              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]
              Mike Luther
              [email protected]

              Comment


              • #8
                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


                ------------------
                Barry

                Comment

                Working...
                X