I might need to set up a Wiki page of some kind containing a design spec, because even fixing that bug will require some extra features.
Case in point: - There is no desire to include MOVUPS instructions because, while they will work for unaligned memory, are much slower than MOVAPS, but MOVAPS will cause a segmentation fault if the memory is not aligned. - There currently no easy way to enforce memory alignment outside of a compiler directive, and that includes forcing the programmer to use it whenever they declare a variable of a vector type, even outside of the unit that contains the actual vectorised code. - If a compiler feature will easily cause crashes unless some additional compiler directives are carefully specified, most users will simply not use it or pass it off as buggy or, at the very least, not friendly. - Only static arrays of Singles or Doubles are identified as vectors by the compiler. Record types that contain, for example, 4 packed Singles (representing co-ordinates) are not identified as such. I'll dwell on this a bit, and see if a plan can be drawn up that Florian and the other senior developers agree on. I think I found my life's calling!! Kit On Mon 11/12/17 13:44 , "Adriaan van Os" f...@microbizz.nl sent: > J. Gareth Moreton wrote: > > > I guess fixing that might be a good > > > starting point. There's also the issue of > > > memory alignment causing crashes. > > > > I (and others I think) would much welcome the fix. WIth regard to memory > aligment, you would have > to test what is already fixed in the current (svn) compiler (and what not) > as the report is from > some time ago. > > > > Regards, > > > > Adriaan van Os > > > > > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
