Announcement

**Michael Mattias** · 29 Jun 2006, 07:05 AM

Um, the way you get the sizes of the segments is to read the message screen when the compile completes.

I forgot the limit but I'm sure it's documented under $SEGMENT

**Aldo Cavini** · 29 Jun 2006, 07:32 AM

Daniel,

I had the same problem in the past - what really solved all the problems was to convert all the SELECT-CASE into IF-ELSEIF-ELSE-ENDIF statements. May be (it's my opinion) there is something in the compiler (i.e. some internal unitialized var) which starts giving problems when the program grows to a very high limit.

Aldo

PS - I posted all what I found to PB support (including some debugging code I wrote myself) starting on june 2003 - Since then, I didn't receive any reply - May be I'm wrong, but till now they didn't even reply I am!

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

[This message has been edited by Aldo Cavini (edited June 29, 2006).]

**Michael Mattias** · 29 Jun 2006, 07:48 AM

>I had the same problem in the past - what really solved
>all the problems was to remove all the SELECT CASE statements

??

I had that problem too but the 'fix' was either to not have segments "close to the maximum [64K] size" **or** to avoid 'deeply nested' loops (FOR.. DO... SELECT CASE... IF ELSEIF END IF ...... END SELECT... LOOP..NEXT) containing ELSEIFs. I resized segments AND changed all my ELSEIFS to SELECT CASE and it worked good.

[This message has been edited by Michael Mattias (edited June 29, 2006).]

**Aldo Cavini** · 29 Jun 2006, 07:56 AM

Michael,

the debug code I wrote consisted in two routines: one to write the memory code of a program to a disk file, the other to compare the memory code to the saved file. The memory code corrupted just after the first SELECT statement execution (absolutely not deep-nested). I submitted a simple test code with the two routines I mentioned to the PB support. But they didn't even reply to tell, for instance, my code didn't had problems on their computers.

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

**Bob Zale** · 29 Jun 2006, 08:02 AM

Mr. Cavini--

The one and only reason you didn't hear from PowerBASIC Tech Support on this "issue" is that they never received any demonstration code from you. If you have an example, I'd suggest you email it to [email protected] and they'll take a look at it.

Best regards,

Bob Zale
PowerBASIC Inc.

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

**Aldo Cavini** · 29 Jun 2006, 08:14 AM

Mr. Zale,

I first sent all this stuff to Lance Edmonds <[email protected]> on june 2003. I asked him for some reply on september 2003 - nothing. On august 2005 I wrote to [email protected] again, and Borje Hagsten replied he sould ask just to you about this problem. Then he replied you didn't know about it, so I sent to him all the stuff again. After another month Borje replied:

"It sounds like some internal buffer size problem to me, but I can only guess. I'll forward it to R&D and hear what they have to say about it - thanks again!"

I never had replies. Nevertheless, I think support should be informed of it, at least since august 2005.

Regards,

Aldo Cavini

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

**Michael Mattias** · 29 Jun 2006, 08:26 AM

>I'll forward it to R&D...

AHA!

I've had five or six things "forwarded to R&D" over the years and not once did I get a reply unless I followed up on it myself.

That said, if you <U>do</U> followup, you will get a response.

"Forwarded to R&D" = "Sent into a Black Hole"

**Bob Zale** · 29 Jun 2006, 08:28 AM

Mr. Cavini--

First you said "...June, 2003. Since then, I didn't receive any reply...". Now you say they did reply, but you didn't like what they said.

I'm sorry to hear you aren't happy, but the fact still remains there is no record you ever sent us any demonstration code. If we don't have a sample, there's little we can do to help you. Perhaps you'd like to reconsider and send an example now? That sounds a lot more productive than just complaining about historical emails.

Best regards,

Bob Zale
PowerBASIC Inc.

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

**Eric Pearson** · 29 Jun 2006, 08:44 AM

> "Forwarded to R&D" = "Sent into a Black Hole"

FWIW, that is completely contrary to my personal -- and extensive -- experience with PowerBASIC support and R&D. There have been glitches, sure, but to characterize it that way is (IMO) unfair.

-- Eric

**Aldo Cavini** · 29 Jun 2006, 08:50 AM

Mr. Zale,

I no longer need a help from you (at least on this "issue"), since I no longer use SELECT CASEs with PB/DOS. I first replied to this forum to help Daniel Raymer solve HIS problem.

About the replies, all I got is "forwarded to R&D", both from Lance and Borje. Really, not too much to be happy.

Sorry at the moment I haven't the time write again to [email protected] There were some 20 mails between us. Are you sure you can't find them?

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

**Bob Zale** · 29 Jun 2006, 08:56 AM

Mr. Cavini --

First, there was no reply at all. Then one reply you didn't like. Now there were 20 emails back and forth? That's very interesting.

Please be assured I'm not going to engage in an argument with you. If you have an example, you'd help everyone by sending it to [email protected] If you choose not to do so, you're simply hurting PowerBASIC, and your friends here. But, of course, that's your choice.

Best regards,

Bob Zale
PowerBASIC Inc.

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

**Aldo Cavini** · 29 Jun 2006, 09:14 AM

I did a look to all that old stuff. More than on the SELECT CASEs statements, the problem resides on the FPU - but since all SELECT CASEs statements in PB/DOS use floating point numbers, the both are strictly related.

The simplest code I can post is the following:

Code:

$dim none
 
$error all on
$debug pbdebug on
 
debugstart:
 
call DebugWrite              ' write the code image to disk
 
call DebugVerify( 1 )        ' first verify
 
a% = 123                     ' integer math
b% = a% * 123
 
call DebugVerify( 2 )        ' verify
 
a = atn( 1 )                 ' fpu: comment out to skip
 
call DebugVerify( 3 )        ' verify
 
if a > 1 then                ' fpu again: comment out to skip
end if
 
call DebugVerify( 4 )        ' verify
 
select case a%               ' fpu again! (even with a%)
case 2
end select
 
call DebugVerify( 5 )        ' verify
 
cls
print "Ok"
 
debugend:
 
' ==========================================================================

' -------------------------------------- write code image to disk ----------
 
sub DebugWrite

local ss&, sp&, es&, ep&, n%, i&

  n% = freefile

  open "b", n%, "debug.dat"

  ss& = codeseg( debugstart )
  sp& = codeptr( debugstart )
  es& = codeseg( debugend   )
  ep& = codeptr( debugend   )

  ss& = ss& + sp& \ 16
  sp& = sp& mod 16
  es& = es& + ep& \ 16
  ep& = ep& mod 16

  def seg = ss&
  put$ #n%, peek$( sp&, 16 - sp& )
  for i& = ss& + 1 to es& - 1
    def seg = i&
    put$ #n%, peek$( 0, 16 )
  next i&
  def seg = es&
  put$ #n%, peek$( 0, ep& )

  seteof n%
  close n%

end sub

' -------------------------------------- verify code image -----------------

sub DebugVerify( p% )

local ss&, sp&, es&, ep&, n%, i&, s$

  n% = freefile

  open "b", n%, "debug.dat"

  ss& = codeseg( debugstart )
  sp& = codeptr( debugstart )
  es& = codeseg( debugend   )
  ep& = codeptr( debugend   )

  ss& = ss& + sp& \ 16
  sp& = sp& mod 16
  es& = es& + ep& \ 16
  ep& = ep& mod 16

  do
    def seg = ss&
    get$ #n%, 16 - sp&, s$
    if s$ <> peek$( sp&, 16 - sp& ) then exit loop
    for i& = ss& + 1 to es& - 1
      get$ #n%, 16, s$
      def seg = i&
      if s$ <> peek$( 0, 16 ) then exit loop
    next i&
    get$ #n%, ep&, s$
    def seg = es&
    if s$ <> peek$( 0, ep& ) then exit loop
    close n%
    exit sub
  loop

  flush n%
  close n%
  color 7, 0
  cls
  locate 1, 1
  print "Image Error on Position:"; p%
  sleep 1
  locate 1, 1
  print "                               ";
  end

end sub

' ---------------------------------------

On my PC I get an error on DebugVerify( 3 ), unless I commend out the preceding statements - in such case I get an error on DebugError( 4 ), and so on.

Again, my old big program started working correctly only after I converted all the SELECT CASEs. The DebugVerify function continued signaling code memory corruption, but commenting out all the DebugVerify calls the program worked (and still works) correctly.

I asked Lance (and perhaps Borje) to tell me if my approach to debug my program was correct or not - I did never receive this answer. May be it's wrong - But it helped me to solve my problem. My guess is, on big programs, the use of both/either the FPU and/or the SELECT CASE statements, can be of some risk.

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

[This message has been edited by Aldo Cavini (edited July 04, 2006).]

**Bob Zale** · 29 Jun 2006, 11:35 AM

Mr. Cavini--

I really should mention that these forums are not a source of official support for PowerBASIC products. You agreed to that premise when you registered. That's why I've asked that you provide any sample code directly to [email protected] Under normal conditions, if you don't send them demonstration code, it just isn't possible to help you.

That said, I reviewed your posted code myself. I'm afraid I must confirm that your program works flawlessly. PowerBASIC compiles it correctly, just as designed, and the executable runs without a flaw, just as designed. Granted, your program displays its own error message, but the error is in the design and logic of your program, not in the PowerBASIC Compiler. The PowerBASIC Compiler works exactly as designed and advertised. If you should happen upon any other evidence of a PowerBASIC problem, please let us know.

One last thing... It's very disruptive to post disparaging remarks like:

"I posted all what I found to PB support...starting on june 2003 - Since then, I didn't receive any reply"

Then, minutes later, you agreed that our support representatives engaged in an ongoing conversation of at least 20 emails. This type of inflammatory rhetoric doesn't really help anyone. I'd appreciate it if you could try to keep it in check in the future. At PowerBASIC, we all try very hard to help every one of our customers.

Best regards,

Bob Zale
PowerBASIC Inc.

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

**Bob Zale** · 29 Jun 2006, 01:03 PM

Daniel--

As to your original question {smile}, PB/DOS allows up to sixteen segments.

Best regards,

Bob Zale
PowerBASIC Inc.

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

**Daniel Raymer** · 29 Jun 2006, 02:36 PM

Wow - when I got 800 replies to my simple posting I was sure that all would be answered. Alas, but an amusing alas, my simple question prompted a flame war.

Finally, Bob the Great (I mean that sincerely, as a long-time PB user) answered half of my question. 16 Segments.

The other half, someone posted that the sizes of the segments are given when compilation is complete. Alas again, I don't see it. I get Lines, Statements, Time, "Success", and "Press any key", but nothing says how big my compiled segments are.

Does it matter that I am compiling to a PBC?

Help, still !!!

Dan

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

**Bob Zale** · 29 Jun 2006, 02:56 PM

Hi Dan!

After you've compiled successfully, press ALT-C then G (Compile menu -- GetInfo) and all will be revealed.

Best regards,

Bob Zale
PwerBASIC Inc.

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

**John Reinking** · 29 Jun 2006, 03:09 PM

Daniel,

Compile outside the PB IDE. At the command prompt,

<pathname\>PBC.EXE <filename>

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

**Daniel Raymer** · 29 Jun 2006, 04:00 PM

...press ALT-C then G

That's the trick I couldn't remember!!! Thanks Bob.

BTW, wasn't that the punch line to a Dilbert cartoon? Something easy to remember like....

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

**Aldo Cavini** · 30 Jun 2006, 01:59 AM

Mr. Zale,

I posted my code here as I already sent it twice to [email protected] (isn't this the correct address?) and nobody replied any technical comment.

I'm still puzzled about what I call the "memory code segment" corrupts during execution. And if I SET 87=NO it doesn't happen, and the program runs to the end without signaling errors. But you are the most expert of PB/DOS - you are surely right.

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

[This message has been edited by Aldo Cavini (edited June 30, 2006).]

Announcement

Segment Sizes after Compile

Segment Sizes after Compile

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment