QL / PASCAL

[Derek_Stewart]

Hi,

I downloaded the updated version of vasm v1.9d and compiled and installed as per Norman's document.

The cross compiler compiled with no errors and I was able to compile a 'Hello World' program and execute the compiled program in a QL Emulator.

Regards,
Derek

[NormanDunbar]

Much obliged ToFro, thanks.

I've also heard on the FPC mailing list that other M68K affected users are happy with the fix.

Thanks again.


Cheers,
Norm.

[NormanDunbar]

Thank you Derek.

Cheers,
Norm.

[NormanDunbar]

I have now been told that the Assembler has been fixed and the new official release is 1.9d, we are requested to switch to using that, rather than the daily release version.

Cheers,
Norm.

[Chain-Q]

Just as an info, maybe someone is still interested - I found a small bug in vlink, that caused non-working QDOS-header executables under Q-emulator at least.The "packed" format relocation table at the end of the binary could have an odd size, which caused the entire binary to have an odd size, and this caused the system to break upon trying to execute the binary. Since yesterday's snapshot, vlink inserts an extra padding byte at the end of the binary in this case. The value was already correct and even in the header, but the file size was not padded.

XTcc binaries were not affected, as they already had a padding before the XTcc metadata was added to the end of the file.

My patch is in the daily snapshot for a couple of days now.

[tofro]

Just as an info, maybe someone is still interested

I definitivly am

That was - at least in my opinion, and I think I deserve one - not exactly a bug in vlink, but rather was a missing work-around. It's an age-old bug in QDOS that it will allocate the stack of an executable whose load-size is odd to an odd address. And the application starting up will silently die with an address error......

[Chain-Q]

not exactly a bug in vlink, but rather was a missing work-around. It's an age-old bug in QDOS that it will allocate the stack of an executable whose load-size is odd to an odd address. And the application starting up will silently die with an address error......

Exactly the symptoms we were seeing indeed. Good to have it confirmed, that we weren't just imagining it. And if it is a bug or a missing workarund - I mean, if you're a compiler and/or linker, and you want to produce executables that actually work on the target retro/legacy systems, you have to take their bugs and limitations into account - and if you don't, and thus you create a non-working exe, that's also a bug.

But I guess rhetorical arguments aside, the important bit is that it works now.