2009/3/10 Andy Dougherty <[email protected]>: > On Tue, 10 Mar 2009, Reini Urban wrote: > >> 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. > > I am suggesting you consider doing just that, for 64bit machines trying to > read foreign 32bit pbcs. > >> 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. > > I don't understand this comment at all. I am not suggesting changing the > native read or write either. I am only considering the problem of 64bit > reading a foreign 32bit file. I see two possibilities: 1) The writer > pays the penalty of making the pbc maximally portable even for this > somewhat oddball case. 2) The reader (the one who will actually *use* > this facility) pays the penalty of having somewhat slower reading. I am > suggesting it makes sense to consider number 2. Of course if you can make > the "penalty" in number 1 very minimal or even non-existent, then that's > great. > > I don't know exactly where in the code this issue is coming up, so I don't > have any informed opinion about how best to change it. I have tried > reading the relevant tickets, but I can't find specific information on > *where* this problem is occuring.
Ah good. So we are talking about the same thing. I even implemented strategy 2, stepping in bytes, and this fixed all my 32/64bit cross issues. It's just a cast of cursor to char* and changing all padding macros. It was in the tt254-64bit-pbc.patch But my rationale was not slowing down the reader too much, only fixing the broken padding code which is too hairy so some mistake crawled in. So I thought, why not give the user the other option also: add a 64bit writer. This will speed up the reader. The only affected costumer is sparc64 (AFAIK yet) so warn on sparc64 that when requesting foreign pbcs he might ask for --64compat pbc's. But maybe this is too confusing and people will think that --64compat is required, not optional. It's just a performance optimization. Where is is occurring? In every (char*)cursor+=4, fetching integers, strings, ops on sparc64 with cc we got bus alarms. Now with -xmemalign=4s we've hidden that. But with native-sized data the ptr advance will be much faster, a simple cursor++. -- Reini Urban _______________________________________________ parrot-tickets mailing list [email protected] http://lists.parrot.org/mailman/listinfo/parrot-tickets
