Dave Higton wrote:
In message <alpine.DEB.2.00.1003191535500.5913@xxxxxxxxxxxxxx> Iyonix PC Owner <iyonix@xxxxxxxxxxxxxx> wrote:On Fri, 19 Mar 2010, Thomas Milius wrote:I spent some time last year to get fimilar with FileSwitch and porting it to 64 Bit. Overall it isn't impossible to change it to 64 Bit (and backward compatible) but it will take a long time. FileSwitch is a critical part and one register usage is the problem which need to be checked from all sides. Only one small failure could lead to a stability desaster.From a programmer's point of view it would be easiest, if you could just present us with a 64-bit ARM processor, as with that, it would just be a re-compile of the relevant parts of the OS. The code in FileSwitch and elsewhere uses the 32-bit wide registers of the ARM as signed integers which means your biggest number is somewhere about 2^30 - which corresponds to 2 GB. So what Thomas has done, is to use one more register in FileSwitch to return (counting) results in, than the original FileSwitch SWIs use. The calling routine is then responsible to compute the 64-bit sum of the two registers involved. So it *can* be done, but will take quite a lot of effort, as "Druck" stated.The existing map format is OK, isn't it - a large file simply means a huge number of consecutive 1s in the map.
The Filecore formats splits the disc in to zones, and files over a few 10's of MB already occupy multiple zones.
The automatic defragmenter, which keeps files contiguous, needs to be changed to cope with files of more than 2^32 blocks.
It only defragments a zone at a time, otherwise it would take as long as Windows.
The directory format needs to be changed to support 64-bit file sizes. RISC OS has already had numerous formats in the past - L, D, E, E+, F, F+... another one won't hurt us. There has to be an API to do many of the existing file operations with 64-bit sizes. The operations that load/save a file from/to memory won't benefit because the RAM can't exceed 2^32 bytes, except that the numbers want treating as unsigned so that files of 4 GB could be loaded/saved. (OK, there can't be more than 2 GB of RAM in an Iyonix.)
All sensible up to now.
The existing 32-bit interface should be deprecated but not removed.
99.9% of all RISC OS software that will ever exist have already been written, remove the 32bit interface and what do you think you'll have left?!
-- Email: druck@xxxxxxxxxxxx Phone: +44-(0)7974 108301 ---To alter your preferences or leave the group, visit //www.freelists.org/list/iyonix-support
Other info via //www.freelists.org/webpage/iyonix-support
