Awful bug...
(~0UL/2+1)....
What's that, you will ask? Well, that was TEH BUG which made all buffered dos operations (the ones done through FGetC, FGetS, FPutC, FPutS, Printf and many more) unusable on x86_64 target. What does this line? Well, it should set the highest bit to one and clear all other ones. This tiny line of code works perfectly... Better than enyone expected in the old times, where C's long was 32-bit...
The struct FileHandle of dos.library contains a tiny buffer used to speed up file operations. The buffer could be therefore in both READ and WRITE modes. In order to set it into write mode, the FHF_WRITE on the filehandle's flags has to be set. The fh_Flags field is of type ULONG - it is a 32-bit unsigned number.
The FHF_WRITE was defined as ~0UL/2+1. Fine. On x86, where the type long is 32-bit, the FHF_WRITE equalled 0x80000000. On x86_64 however the type long is 64-bit wide. The FHF_WRITE flags was therefore 0x8000000000000000. And this value does not fit into ULONG variable......
I have redefined the FHF_WRITE variable a bit and suddenly the buffered operations do work, as you may see on the screenshot (yes, the whole shell uses buffered operations :-))). Finally, after one month of useless fight I continue on the x86_64 port. Sweeet.
What's that, you will ask? Well, that was TEH BUG which made all buffered dos operations (the ones done through FGetC, FGetS, FPutC, FPutS, Printf and many more) unusable on x86_64 target. What does this line? Well, it should set the highest bit to one and clear all other ones. This tiny line of code works perfectly... Better than enyone expected in the old times, where C's long was 32-bit...
The struct FileHandle of dos.library contains a tiny buffer used to speed up file operations. The buffer could be therefore in both READ and WRITE modes. In order to set it into write mode, the FHF_WRITE on the filehandle's flags has to be set. The fh_Flags field is of type ULONG - it is a 32-bit unsigned number.
The FHF_WRITE was defined as ~0UL/2+1. Fine. On x86, where the type long is 32-bit, the FHF_WRITE equalled 0x80000000. On x86_64 however the type long is 64-bit wide. The FHF_WRITE flags was therefore 0x8000000000000000. And this value does not fit into ULONG variable......
I have redefined the FHF_WRITE variable a bit and suddenly the buffered operations do work, as you may see on the screenshot (yes, the whole shell uses buffered operations :-))). Finally, after one month of useless fight I continue on the x86_64 port. Sweeet.
2 Comments:
Its not 32bit muchless 64bit and it sure cant multitask.
Are u not orginally amiga people. I would think u are there and then u have real mulitasking and true 64bit.
Wow dude, it looks great! A friend of mine once said the most difficult bugs to fix were the most obvious..
It's great to see that AROS won't be left out of 64 bit computing!
Post a Comment
<< Home