Announcement

Collapse
No announcement yet.

Max number of statements 'tween line numbers?

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

  • Max number of statements 'tween line numbers?

    I wonder?

    No matter how carefully you decide you'll allocate actual line
    numbers in PB 3.5 for program use in error handling mostly, there
    comes a time...

    A time with 25,000 lines per program including CALLS, libraries,
    Units, whatever - that it is necessary to make statements between
    contiguous physical numeric line labels in the code. At least that
    has happened here.

    OK. So what? Well, you can use the ":" mark to delimit statements
    in the source code with many of them on one line.

    OK .. you can also, in the quest to make code more understandable
    and easier to maintain, simply move to what I've done totally and
    go to one line per statement.

    But .. I'm curious. Is there a maximum number of physical statements
    either coded with ":" separators on one line, or into single none
    labeled pure one statement per line uses you can make between two
    physical adjacent number sequence numeric line labels in PB 3.5.

    **********************************

    Reason I'm curious is that once again I just spent another seven hours
    here chasing the mysterious SYS3170 error in very large executables in
    OS/2 DOS-VDM's in huge PB executables. This error is:

    [C:\]help sys3170

    SYS3170: A program in this session encountered a problem and
    cannot continue.

    EXPLANATION: The process was ended because the program generated
    an unhandled fatal user (non-system) exception through DosRaiseException.

    ACTION: If you purchased this program, contact the supplier of the
    program. If you are the developer of this program, refer to the
    information in the register.

    ************************************

    There is no way to debug these large programs here with PBD as there
    simply isn't enough memory to even operate them, even with 675K of
    free memory at the raw command prompt line. Thus I wind up hand
    inserting little break point traps line after line one at a time
    until I can find the exact place where the trap takes place.

    Here, once again, hours later I'm faced with the 'solution' which is
    a simple numeric line lable in the source of 37899 in the below. If
    I don't add a line lable to it we get the SYS3170 .. or SYS3176
    is possible too. With the following, absolute stable runtime:

    Code:
    SUB AP37894 (DTMEORG$, Y2$, GFF%, HT%, L%, LL%) PUBLIC '        CVRTTIME:
    37899   Y2$ = DTMEORG$ '                        Set to convert selected time
               IF VAL(Y2$) < 0 OR VAL(Y2$) > 2359 THEN
                  GOTO APDCV1 '                     Units per hour
               END IF
               IF LEN(Y2$) < 3 OR LEN(Y2$) > 6 OR INSTR(Y2$, ":") > 0 THEN
                  GOTO APDCV1 '                     Is bad
               END IF
               IF LEN(Y2$) > 4 THEN
                  GOTO APDCV1 '                     Is bad
               END IF
               IF VAL(Y2$) < 1159 THEN '            Fix it up
                  Y2$ = Y2$ + "AM"
               ELSE
                  Y2$ = Y2$ + "PM"
               END IF
               IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN
                  GOTO APDCV2
               END IF
    APDCV1:
             GFF% = 1 '                             Set bad time flag
             EXIT SUB
    
    APDCV2:
         etc..
    Now I already know from long BITTER experience I can't put any actual
    operational code directly adjacent to a non-numeric line lable as
    is shown above. But that's another story..
    Remove that 37899 numeric line lable and the whole DOS-VDM session
    comes crashing down. It's the first time in all these years it has
    popped to my attention that could this be related to the total number
    of statements between two adjacent numeric line lables? There is a
    lable above it statements back of 37899 and, in this case, a numeric
    line lable for error trap reporting purposes of 37902.


    Thoughts?



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

  • #2
    >Thoughts?

    Not directly on topic, but you asked....


    Code:
    SUB AP37894 (DTMEORG$, Y2$, GFF%, HT%, L%, LL%) PUBLIC '        CVRTTIME:
    37899   Y2$ = DTMEORG$ '                        Set to convert selected time
               IF VAL(Y2$) < 0 OR VAL(Y2$) > 2359 THEN
                  GOTO APDCV1 '                     Units per hour
               END IF
               IF LEN(Y2$) < 3 OR LEN(Y2$) > 6 OR INSTR(Y2$, ":") > 0 THEN
                  GOTO APDCV1 '                     Is bad
               END IF
               IF LEN(Y2$) > 4 THEN
                  GOTO APDCV1 '                     Is bad
               END IF
               IF VAL(Y2$) < 1159 THEN '            Fix it up
                  Y2$ = Y2$ + "AM"
               ELSE
                  Y2$ = Y2$ + "PM"
               END IF
               ' next test is totally useless becuase above always
               ' makes the last character an upper case M
               IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN
                  GOTO APDCV2
               END IF
    APDCV1:
             GFF% = 1 '                             Set bad time flag
             EXIT SUB
    
    APDCV2:
         etc..
    You know, Mike, in your other post you query about the difference in performance between SELECT CASE and IF..ELSEIF blocks.

    If this is typical code you are looking at, you are whistling past the graveyard. The code here is exceptionally redundant and uses the string engine far more than it needs to.

    If I haven't missed something here, you are editing a time. The rule is the length of string must be exactly three or four characters, because you test for LEN<3, LEN>6 and LEN>4) and all failed tests "GOTO APDCV1" (which sets GFF% = 1 and EXITs); must not contrain a colon (although I would think it must be numeric, period); the HHMM must be in range ; and if the time passes the edits, a formatted "AM/PM" time is output.

    You are testing LEN and VAL of the string multiple times... even when the string will fail a later edit.

    I suggest we might try something like:
    Code:
      Y2$ = DTMEORG$ '                Set to convert selected time
      LY2% = LEN(Y2$)               ' take length only once so we can do integer compares
          SELECT CASE LY2% 
            CASE 3%, 4%             ' the only valid lengths
               VY2% = VAL (Y2$)     ' only need to test VAL if length is in range, right?
                                    ' so take it only once instead of twice
               IF VY2% < 0 OR VY2% > 2359 THEN
                  GOTO APDCV1                   ' out of valid range
               END IF
              ' string is now known to be correct length and its VAL is in range
              ' so what could have screwed this up? Perhaps a colon chararter?
               IF INSTR (Y2$, ":") THEN
                  GOTO  APDCV1
               END IF
              ' so fix up the string (doing the integer compare instead of taking VAL again)
               IF VY2% < 1159 THEN 
                  Y2$ = Y2$ + "AM"
               ELSE
                  Y2$ = Y2$ + "PM"
               END IF
               ' --------------------------------------------------------------------
               ' This test from original code is totally useless because above always makes
               ' the last character of Y2$ an upper case "M", so the test is ALWAYS true;
               ' so get rid of it and just GOTO the "passed edits and formatted" label
               ' (this must have been some kind of 'emergency edit' which got left in)      
               ' IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN
               ' --------------------------------------------------------------------
               GOTO APDCV2
    
           CASE ELSE            ' just exit to error point, invalid length
              GOTO APDCV1
    
       END SELECT               ' of length

    I 'may' have posted here on at least two occasions that worrying about which particular compiler functions you use to test/compare/jump is unlikely to produce as much performance improvement as a careful look at your own code design.

    I'm not trying to show you up or anything; I'm just using this as an example of what happens when you modify code many times over the years (no code lives as long as yours has without lots of modifications) and then wonder where your blazing speed went.

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

    Comment


    • #3
      You are totally correct Michael ..

      I 'may' have posted here on at least two occasions that worrying
      about which particular compiler functions you use to test/compare/jump
      is unlikely to produce as much performance improvement as a careful
      look at your own code design.

      I'm not trying to show you up or anything; I'm just using this as an
      example of what happens when you modify code many times over the
      years (no code lives as long as yours has without lots of modifications)
      and then wonder where your blazing speed went.
      And your critique absolutely has to be valid for a lot more of my
      code than what I posted above. Sadly. And, no, you are not trying to
      show me up or anything. Plus what you posted here, I hope, will help
      a lot more folks than me to think carefully about what you have said
      not only about this, but in a heck of a lot of other comments you've
      made in the forums Michael. You are a major contributor here and have
      been, in my eyescape, and the time to do that doesn't come free either.

      Thank you.


      Not only are you correct, I've got what it takes to document what you
      say from the work here to actually show people how right you are and
      why what you say is so important.

      The above code chunk actually supports what you are saying in your
      critique of my work far more than you expected, sigh. The calendar
      module was 'taken' from parts of the broadcast station log programming
      codework, originally 'extracted' for concept 'can we do this?' as my
      current records show, in 1991.

      One of my utilities I wrote originally in Basic for my Heathkit Z120
      looks for string data in any collection of files for a file name slice
      overlay description match in a given file path. I looked for the
      following text in this case, "RIGHT$(Y2$,". Admittedly I'm lax in that
      from the files here I can't go back prior to 1985 in that we have
      operating system issues for the work that was originally done in eight
      inch floppies, the Heathkit Z120 and H89 boxes that *ARE* still there
      for proof. But this'll show exactly how right you are Michael, grin.

      From a WordStar file with the following internal trace date in the
      128 bytes from the control header at the top of every WS format
      file, grin:

        02-15-85
      From that 1985 file we find the following code where it was pulled
      from the 1976-era broadcast station operations code that started in
      BASIC at radio station WTAW in College Station, Texas. Incidentally,
      there are very few "W" broadcast stations west of the Mississippi
      river in the USA instead of KORA etc. The original Aggieland student
      EE Department crew got the call letters from the FCC for "Watch The
      Aggies Win". And the their first broadcasts were indeed of football
      games here in CS.

      I can go back to 286CPU code in CPM if we need to but this'll do
      as to show how right you are! From that February 1985 file:

      Code:
      7920 ' - Select Hour wanted
      7930 GOSUB 9440:IF TZ THEN GOSUB 10220
      7940 PRINT KK$;:IF TZ THEN GOSUB 10310
      7950 LINE INPUT Y2$:IF Y2$="E" OR Y2$="e" THEN 8080
      7960 IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
      7970 IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN 7980 ELSE 7930
      7980 ' - Wk hr
      7990 IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
      8000 Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
      8010 HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
      8020 IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
      8030 GOTO 8050
      8040 HT=HT+12:Y2$=RIGHT$(STR$(HT),2)+":00PM"
      8050 IF HT=24 THEN MID$(Y2$,6,2)="AM":HT=0:GOTO 8080
      8060 IF HT=12 AND RIGHT$(Y2$,2)="AM" OR HT=12 AND RIGHT$(Y2$,2)="am" THEN HT=0
      8070 L=INT(VAL(MID$(Y2$,4,2))):LL=L:IF L<1 OR L>60 THEN L=0
      8080 GOSUB 9970:RETURN
      At another time you made a very important point in working with me
      here that one really needs to keep accurate revisions files and old
      source information so you can document all the changes. I try. BTW,
      one day when I get the time, Will Honea showed me how to re-configure
      the OS/2 floppy diskette driver loader parameters so I can actually
      tie one of those eight inch floppy or an older 5-1/4" floppy diskette
      with the Heathkit DOS format to the current OS/2 operating system!
      We could go all the way back to just after CP/M for this quest here if
      we want. But thistle dew .. I think, to show the color of the blossom.

      Marvelous this OS/2 operating system. Not only do we have USB and all
      but we go back all the way to just after CP/M on the same box!

      GDRFC!

      What this whole thread now shows though is an even more important look
      at project techniques, 'wrongs' and 'rights' that most would never
      see. We program as people; each of us are different. We each see
      our world bounded by our own limitations, which all of us have. As
      an MBA in corporate planning from Texas A&M, strongly looking with
      eyes that see text data and realizing that all professional management
      is really the same, I've sought to containerize that concept.

      For over 40 years now.. And I'm getting closer and closer each year.

      Yes, the art is in the deal and numbers control it. But it is still
      the TEXT and the variable length string data that are the mechanisms of
      payment for whatever. As I can see over all this.

      And yes, string data. an array of characters if you 'see' it that way,
      grin, is best compared and directed through integer math pointers!
      A truely competent 'reader' only should read a line once. The step
      to representing that text and what it means in the fastest possible
      recall of it, can't be efficently applied to the text words to describe
      what you view, if you have to read the line over and over again before
      you act on that data each time. You may get paid by the text, but
      you'd better be able to index it by integer pointers if you ever
      want to make a profit.

      My problem is the template that encapsulates all this is so huge as
      for what I really see. So many vectors; so little time. You have
      to simultaneously, in real-time, keep key data from leaking out of
      the control template before you have been really hurt by what's been
      'wrongly' taken from your pie. And yes you are right again.

      You have to periodically review the whole project and try to even
      re-design it and completely look at things differently as the
      focus on the canvas changes. Yet, Michael, on that special night
      when you catch a glimpse of the whole picture, the moon only is
      there for maybe ten minutes over the whole horizon .. which has
      all the other details in it you must remember?

      And it is a hundred years until that precise picture comes back
      again for you to see? You won't live that long, so you begin
      to work at capturing the beauty. You must.

      My problem is precisely as you say. If I were a better reader, I'd
      realize in my programming that I'd be better able to point to the
      solutions with mathematics, than I now do as I see things. Yes,
      the code above shows I have made real progress since 1985 at making
      things more maintainable and clear. But there is a long way to go
      down this management trail of stary night events, Michael.

      Your point is very well taken. You are correct. At the same time
      the overview is still massively before me. There is still art in
      the deal which I see which has to be on the canvas as a working
      calendar module before I can go back and touch up the canvas.

      It's like looking at a painting and seeing the real overview, knowing
      what might be done, but still not finished with the painting to be
      able to handle the details.

      I was in the room at a Holiday Inn in Baxter, Iowa, when a young guy
      named Charlie McLain, on New Year's Eve in the 60's said, "Folks,
      here's a song we're thinking of recording I like to try on you.
      See what you think about it," And then, for the first time, in
      public, he sang, "Stary stary night ... Amber fields .."

      Two years ago, Vincent Van Gough's painting "Stary Night" was on
      exhibit at the Houston Museum of Fine Art. You bet I went to see
      it. And I GUARANTEE you that you ain't seen what Vincent wanted
      you to see until you've looked at the original. For the admission
      money they were right in step with technology. You got a personal
      hand held. You punched in the integer number of the painting in
      this massive exhibit of fine art and a custom audio track talked
      to you about the painting at which you were looking.

      Yap, yap .. all the technical details about Vincent's trip to the
      monastery and so on. As you would expect, there was a large crowd
      in front of that painting, including a tour clump of extra-paid-for
      folk led by one of the exhibition planners. I wasn't in that group,
      just happened to be there then. The guide asked, "Any questions?"

      Ny overview broadcasting engineering management personality got the
      best of me. I asked him, "If you've gone to all the beautiful work
      to put this wonderful modern audio track together for the show,
      and this painting, why didn't you background this track with
      the music for Stary Stary Night from McClain's Vincent?"

      Answer, "Gee, I never thought of that!"

      Gee, Michael, you've just done exactly the same thing to me, and
      you are so correct. All I can tell you is that it's awfully hard
      to see the details on the canvas for the real nuances in the scene,
      when you have to go over and over the work 'cuz the hairs fall out
      of the brush every time you go to add an impression swipe at the
      canvas.

      But the brush issue is only another of the same sort of things that
      *ALL* of us face when we try to really put out work which is on the
      edge of what can be done with the technology resources. That at
      the same time economics focus all of us on what we can and cannot
      afford to add to our pallet and application tools.

      I really do understand why sometimes we have to work with things the
      way they are. But realizing that even not knowing if some otherwise
      unseen limit in the tools we have, might cure things, if I just knew
      it, makes me ask. Even IBM, as big as it is, has a phrase, "Customer
      has a workaround." Even they are important.

      It takes a lot more than any of us have as individuals. or even big
      corporations sometimes. to define what really can be done in any
      creative work. And believe me, what you offered is important to me.
      I'll try, when I can get the thing working, again, this time, on the
      canvas, to see what highlights can be placed on it to make it better.

      Thanks again for your time. I guarantee you that the time you have
      spent here, along with that of many others, has made my screen
      look brighter, handle more data, and move faster than I ever could
      have done by myself.

      Meanwhile.

      Does anyone here have any idea what the statement limit might
      be between two consecutive numeric line lables in PB 3.5?

      Inquiring mind wants to know.





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

      Comment


      • #4
        Just a thought... is it possible you are referencing a line number in a different code segment (not a different module, just one line referencing another line with one or more intervening $SEGMENT directives?

        I never really thought about it before, and since I never had a problem with it I assume the compliler either picks this up or doesn't care, but as long as the question is from Mars you may as well consider a suggestion from Jupiter.


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

        Comment


        • #5
          I noted something in your initial code that I wanted to comment on.
          With PowerBasic, there are two ways to identify line lables:

          (1) Use a standalong line number, such as 12345, which optionally
          can be followed by a colon (

          (2) Use a suitable name, similar to a variable name, but follow
          it with a colon ( and allow no statement on that line.

          In general, there are three techniques for renumbering or renaming
          lines in a BASIC source file for use in PowerBasic:

          (1) Renumber every line, possibly with an incremental step, such
          as 10, or 20, in case you want to add new statements in between,
          This assumes that line numbers will be used or assigned in
          sequece, from low to high, over the course of the program.

          (2) Renumber only referenced lines, such as those that are
          targeted with GOTO or GOSUB, and eliminating line numbers that
          are not really needed to compile the program. This reduces the
          size of the source code, show you where join points occur in
          the code from other areas in the program, but reduces the value
          of ERL if an error occurs and you are trying to trap for it.

          (3) Rename line numbers making them names, such as taking 12345
          and renaming it "L12345:", so as to get rid of line numbers in
          the old BASIC style (BASICA, GWBASIC, and others). Again, if a
          line number is not actually used, it is removed.

          Typically, programs that do this for you might be called a
          Renumber, Labler, ReLable, or one of the services provided by
          a Format, ReFormat, or Convert program.

          Another thing that a Format, Reformat, or Convert program might
          do would to break up very dense lines where multiple statements
          appear separated by colons. This may appear to make the program
          much larger, but it also means you now have room to either add
          new line numbers for every statement (for more specific trapping)
          or you now have space per line for adding more comments to your
          source. Neither change will make the resulting compiled program
          any arger. And another advantage of a Format, ReFormat, or
          Convert program is that it can standardize the source, apply
          rules of capitalization, indentation, and other benefits.

          I want to make sure that you know that the name "Format" is also
          shared by a utility for reformatting disk drives, and we do not
          want you formatting disk drives by accident. But it is one of
          the names sometimes employed for modifying source code files.

          I seem to recall a converter utility called QB2PB, which did a
          pretty good job converting QBASIC and QuickBASIC ASCII source
          files to PB/DOS. It could also handle GWBASIC and BASICA
          source files and convert them over. There were some problems
          with graphic statements because QBASIC and QuickBASIC use a
          different graphical coordinate system than adopted by PowerBasic.

          The thing about PowerBasic is that it can be configured to use
          Conventional Memory, Expanded Memory, and Extended Memory, so
          that you had far less reason to be concerned with the 640 kb
          limits of DOS.

          Of course you also have the option to convert over to PB/CC in
          place of PB/DOS. PB/CC has evolved quite a bit from the earlier
          versions of BASIC, which means a lot more built-in functionality,
          but it is not so far from them that it also makes it too hard to
          adapt the source code.

          Towards this end, lets take a look at another piece of your code:

          Code:
          7920 ' - Select Hour wanted
          7930 GOSUB 9440:IF TZ THEN GOSUB 10220
          7940 PRINT KK$;:IF TZ THEN GOSUB 10310
          7950 LINE INPUT Y2$:IF Y2$="E" OR Y2$="e" THEN 8080
          7960 IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
          7970 IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN 7980 ELSE 7930
          7980 ' - Wk hr
          7990 IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
          8000 Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
          8010 HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
          8020 IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
          8030 GOTO 8050
          8040 HT=HT+12:Y2$=RIGHT$(STR$(HT),2)+":00PM"
          How about instead:
          Code:
           ' - Select Hour wanted
           7920 GOSUB 9440
           7930 IF TZ THEN GOSUB 10220
                PRINT KK$;
                IF TZ THEN GOSUB 10310
                LINE INPUT Y2$
                IF Y2$="E" OR Y2$="e" THEN 8080
                IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
                IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN
                  GOTO 7980
                ELSE
                  GOTO 7930
                END IF
          7980 ' - Wk hr
                IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
                Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
                HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
                IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
                GOTO 8050
          8040 HT=HT+12
               Y2$=RIGHT$(STR$(HT),2)+":00PM"
          8050
          When you do this, you begin to see that the line numbers can be
          made into lables, and the lables can have meaning. The GOSUB
          and [some implied] GOTO commands can jump to labels that are
          named to have some meaning in context, such as AM: and PM:.
          Fact is, some GOSUB commands can be replaced with SUBs or
          FUNCTIONs that are named for the tasks that they perform.

          What you had to do with BASICA, GWBASIC, QBASIC, and QuickBASIC
          were what you had to do at the time, but techniques and methods
          can be refined over time. With earlier BASICS, you sometimes
          could only perform one statement or multiple statements with
          colon separators on a single line - there were no multi-line
          IF structures with ELSEIF, ELSE, and END IF to help you. And
          for structure, you did not have SELECT CASE, CASE, CASE ELSE, and
          END SELECT, what you had was ON GOTO or ON GOSUB to contend with.

          Things are so much better now that it is worth adapting. As to
          adapting your code to use the new functionality, that is your
          call. You can usually still use it as originally written, or you
          may find value in at least a partial rewrite.

          ------------------
          Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

          Comment

          Working...
          X