2009/3/9 Parrot <[email protected]>: > Comment(by doughera): > > I don't understand this ticket at all. What is this hypothetical "-- > 64compat" ? > > I do see this puzzling note in auto/alignptrs.pm: > > # On 8-byte ptr_alignment we cannot read 4-byte pbc's. Warn the user > about it. > > But surely this is just a limitation of the current pbc reader code. I > don't see why the appropriate fix would be to ask 32-bit systems to pay a > penalty here instead of changing the reader code. It is certainly > possible to read 4-byte integers on an 8-byte system. You may have to > read and copy the data, but it can be done. If there's a penalty to be > paid, I think it's fair to have the foreign reader pay it.
Sure, we can fix the reader stepping in byte steps, and not in native ptrsize steps. But it was decides to do it that way, probably it's a bit faster. I'm not the one to change that just for 64bit cpu's. So for those Sparc64 machines with strict 8 byte ptr_alignment which want to read 32bit pbc's, we might either add this --64compat mode optionally (emit 64bit code on 32bit machines) or teach the user to use pbc_dump -o repacked.pbc The native read and write is not touched this way. _______________________________________________ parrot-tickets mailing list [email protected] http://lists.parrot.org/mailman/listinfo/parrot-tickets
