Request For A Pascal Compiler Extension

[rodprince]

While porting our code from IA64 to X86, I ran into some very interesting code that would reach into the "Pascal File Variable" / "File Control Block" check to see if there is any unwritten data in the file buffer and flush that data to the terminal screen via a $QIO and reset the pascal file buffer back so that it does not contain any data.

First let me start off by saying, I have no idea where the "values" came from for the offset to the what the code is calling the "FCB" (assume File Control Block). I ported the code from Vax assembler to AXP Pascal back in 95(?). Essentially, I just used the same values the assembler code was using for the offsets, it all worked, we turned the lights off and called it a day. When we ported to the I64, the values still worked, was an easy day so to speak. I can say the values still work today on VSI Pascal compiler, but it’s a bit "sketchy" to just reach into the pascal text variable wack some bits/bytes around and hope for the best. At some point, that record is going to change, and well things are going to go sideways.

My first question, is there a way in VSI Pascal to get the compiler to write all the data in the lazy-io buffer without disabling “carrage_control:= none” in the open call? Maybe some special pas$flush() call that I am not aware of?

My second question, assuming there is not a way to already do this is, what is the procedure for going about officially asking for an extension to be added to the pascal compiler? The how many "franklins should I be wrapping around the request" question.

Rod

[jreagan]

The good news (as you found out) is that those data structures (the FCB (file control block), PFV (pascal file variable), etc.) are all 100% identical to their Alpha/Itanium counterparts (including any embedded 32-bit pointers). [I was toying with the idea of widening pointers, but I figure somebody would catch me. It would have moved your offsets.]

The CARRIAGE_CONTROL := NONE trick is still the "recommended solution". The suggested PAS$FLUSH or something has been suggested in the past and I think it could be made to work. However, it wouldn't be in the E9.2-3 release (already in field test). Even if added to the next release, you'd still have to make due with your hackery for older releases.

There are PAS$FAB and PAS$RAB to get those RTL data structures for any PFV, but it is the internal FCB that you need to operate on). They have been there since V2.0 days and are documented in the UM somewhere.

It is 2024, no more "write the suggestion on the back of a $100 bill", I'll just post my Venmo link

[arne_v]

Curious. Is the problem to get:

Code: Select all

[inherit('sys$library:pascal$lib_routines')]
program problem(input,output);

var
   i : integer;

begin
   for i := 1 to 10 do begin
      write('*');
      (* some flush *)
      lib$wait(%f_float 1.0);
   end;
   writeln;
end.

working as expected?

Added in 19 minutes 20 seconds:
Aka work like:

Code: Select all

[inherit('sys$library:pascal$lib_routines','sys$library:starlet')]
program problem(input,output);

type
   pstr = varying [255] of char;
   word = [word] 0..65535;

function write_direct(buf : pstr) : integer;

var
   stat : integer;
   ch : word;

begin
   stat := $assign(devnam := 'TT', chan := ch);
   if not(odd(stat)) then return stat;
   stat := $qiow(chan := ch, func := IO$_WRITEVBLK, p1 := buf.body, p2 := buf.length);
   if not(odd(stat)) then return stat;
   stat := $dassgn(chan := ch);
   if not(odd(stat)) then return stat;
   return SS$_NORMAL;
end;

var
   i : integer;
   buf : pstr;

begin
   for i := 1 to 10 do begin
      writev(buf, '*');
      write_direct(buf);
      lib$wait(%f_float 1.0);
   end;
   writeln;
end.

[rodprince]

Arne, as John pointed out, there is no "real" problem yet. The magic offsets we are using to reach into the pascal compiler's data structures are all still valid.

Since you asked, I am going to try and explain our situation and how we are doing things. All of our operator control screens are written in pascal. They all call write() or writeln() to write data to the terminal. When we want to read from the terminal/operator, we typically use a $QIOW() to get the users input.

The problem or concern starts to appear when you consider the Operator expects the blinking cursor to be on the field they need to enter the data for. The Pascal code has been using VT100 escape sequences to write data to the screen. It might have updated a little bit of information at Line 3, col 6. Then put a little bit of something else at Line 6, col 10. Then when we wait for some input from the user, the cursor needs to be at the correct location on the screen so the operator knows the context of what they are trying to answer. Typically the code would issue a write() with the escape sequences of where the cursor needs to be located for the input read. The $QIO/$IO_READPROMPT code would then look at the pascal compiler buffer, calculate what is remaining to be written to the screen, and use that as the prompt for the $QIO. This puts the blinking cursor at the right location and the operator will answer the question (or not, but that is not really a software issue).

Rod

[arne_v]

I don't know the code base.

But why stuff it into output in the first place? If you stuff it into a string it would be ready.

[rodprince]

That's a really good question.

Keep in mind, I was just one of the young 'green' guys back in 86 when I started. I am not sure, I could actually find anyone that could answer that question today. All I can say is things were a little different back in the early 80's. All the options that are available today might not have been available then. Maybe the 11/730's did not have enough memory or some other resource to support doing it any other way. Perhaps that was just the way they understood how to get the job done.

But you are correct, should we need to change the way things work, we will change our interface to the $qio() routine to allow the caller to specify where the $qio() should be positioned at. A simple writeln() will flush anything out, then the $qio will just position the cursor correctly and the issue will be resolved. Well other than going thru 150(?) files and 230,000+ lines of code to make sure it all still works correctly.


Rod