Virtual Pascal

Classic Object Pascal for free

I think I've fond a really bad bug in VP, which seems to manifest itself in two different ways:

If the total source of a program exceeds 32k lines,

1) the generated assembler listing will at some stage be corrupted

2) in this case inserting a breakpoint seems to overwrite something, causing (access) errors at random other locations in the program when run in the IDE.

So far I've not been able to figure out where the 32K ($7fff/0x7fff) limit comes from...

Not a very happy bunny...

Views: 149

Reply to This

Replies to This Discussion

Hi Robert,

Maybe dividing your source code into separated include files will solve the problem?

Hi Jean-Luc,

The source is already made up of one main file with 58 "{$i other}"ones...

I can (probably) solve it by splitting each of these up in two parts, one with the procedure(s) coded in in-line assembler, the other with the procedure(s) coded in Pascal, but I like the current set-up, as it allows me to make the changes in parallel in one and the same file. And in case you ask, yes the entire program is now written in in-line assembler, which in some cases no longer bears any resemblance to the original code generated by VP. You can find a copy in lift32bit.rar on my Google drive , and emphatically "No!" LIFT.EXE does not contain a virus.

I don't see the direct link between lines and some code size metric the compiler would care about.  Maybe in debuginfo (which would explain the breakpoint), but still that is a bit vague.

If you generate the assembler outside the IDE with the cmdline compiler, is it then also corrupted? Afaik the IDE is based on FV which has many 16-bits limits.

I only use the command-line compiler, and only use the IDE when I've got a problem that I cannot solve without looking at the actual assembler code, in essence that means that it's only used when I need to look at what's happening when I replace Pascal with in-line assembler, and more specific, when that in-line assembler contains DB'ed MMX code.

The listing problem showed up when I wanted to convert two new procedures from VP generated assembler into something more palatable, and suddenly output was missing, with output of a procedure starting in the middle of another - the generated code seems to be OK, as the output still matches the "master" source, which is written in PL/I and runs on z/OS.

The debug problem shows up when I use breakpoints, and/or


  int 3


code, when I suddenly get access violations in code that's not been touched at all, indicating that something somewhere overwrites something. Haven't actually looked at differences in code-offsets, but that might give some clues, when combined with relative line-numbers. Not insurmountable problem is the fact that the code is spread over one main file, referencing one unit, and with 58 "{$i others.pas}" files.

Scanning the VP source for obvious 16-bit values has as yet not yielded anything tangible.


© 2022   Created by Allan Mertner.   Powered by

Report an Issue  |  Terms of Service