Ulrich Weigand wrote:
> I've again been playing a little with Wine on Solaris/Sparc, and noticed
> that while the endianness issues are now fine
Great.
>WRC will still crash with
> bus errors due to unaligned memory accesses when running on Sparc.
Bummer, this is the next issue.
> Unfortunately, this is not just a problem of fixing a few generic
> access routines (like put_word etc.), but the assumption that arbitrary
> access is possible pervades a lot of WRC code, most severely all the
> bitmap/icon/RIFF conversion routines in newstruc.c.
Actually, the accesses are not that scattered arround (well, I know the
code and know where to look {mostly}).
As you noticed, the major work is in the code that interprets the RC
data into some structures (mostly located in genres.c, newres.c and
parser.y). This needs to be streamlined anyway.
[snip]
> Do you intend to fix these alignment issues or should I send a patch?
> Unfortunately, there is probably no method to fix this that isn't
> either ugly (by introducing explicit cases all over the place) or else
> reducing efficiency on Intel somewhat (by always accessing single bytes) ...
Yes, I intend to fix it, but it is not on the top of my list (its
second/third). However, I don't know whether that will be within a
couple of weeks though.
No matter how it is solved, it will always be ugly when looking at the
code. I do intend to bytewise the access comletely so that all platform
work.
Another issue is that wrc depends on sizeof(int) ==
sizeof(<any-pointer-type>) (== 32 bits). This is save on 32bit
platforms, but not necessarily true on 64bit platforms. This is a major
problem for some of the static casts performed throughout. I'll have to
go through the entire code to fix that and do some major reworking of
the propagation code (mainly parser).
> B.t.w. another minor problem I notices: you're generating .word directives
> in the output assembly files to create 16-bit wide data fields. Unfortunately,
> on Sparc .word will create a data field the size of a standard machine word,
> i.e. 32 bits. If you use .short (or .half or .hword) you're guaranteed to
> get 16 bits on all platforms (at least when using GNU as).
Oh yes, that one I forgot last time to do; you mentioned it already.
That shouldn't be too hard to change.
Greetings Bertho
