In article 200112040107.CAA20666@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
The bison generated files (parse.[ch]) are supplied with source distributions (not CVS). My patched changed the source (parse.y), so bison was needed to regenerate them (I could have sent patched for them as well, of course, but I didn't think of it, since I usually only make patches of the real sources.)
Thanks for explaining. It wasn't a problem, just a curiosity.
However, testing martin2a.pas on Sparc and MIPS revealed another problem. These processors (as typical for RISCs) have strict alignment requirements for word accesses, e.g., they can't read 32-bit values from addresses not divisible by 4. The set field of the (now really) packed record is not at an aligned address, and the RTS set routines do word access.
I see the following possible solutions:
- Always align sets in packed records. This would break your binary
files again.
Maintaining backwards file compatibility is nice for us but not essential although if it is going to change then it would be nice if any other imminent changes were done at the same time.
- Do it only on platforms with alignment requirements. This would
increase the binary file incompatibilty between platforms. They're now not fully compatible due to endianness, but such a change would add another important issue which would not be easy to work around (i.e., it would be almost impossible to use such binary files in a platform-independent way).
Yes we have struggled with those sort of issues in the past and it does get messy.
- Change the RTS set routines to byte accesses. That's easy to do
(and has been discussed here some months ago), but would decrease the efficiency.
Efficiency is not a big issue for us. Our code would just about run on a Z80 using UCSD interpreted p-code and ran quite reasonably with critical sections native coded. On todays processors we struggle to get the processor usage above 5% when supporting 50 users. However I appreciate that efficiency may be very important to other users.
- Let the RTS set routines check (on each invocation) if access is
aligned. If not (and the platform requires it), use special code (like for packed arrays); otherwise use the faster word access.
This is presumably the most difficult solution. How many places in the RTS would require changing?
Summary. We are happy to go along with the majority view but would ask that as many changes as possible that affect binary compatibility are made together rather than in a series of small changes across a number of versions.