[iyonix-support] Re: File-core limit of 256GB - is it on the list?
- From: Dave Higton <davehigton@xxxxxxxxxxxxx>
- To: iyonix-support@xxxxxxxxxxxxx
- Date: Fri, 19 Mar 2010 20:03:42 GMT
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 automatic defragmenter, which keeps files contiguous, needs to
be changed to cope with files of more than 2^32 blocks.
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.)
The existing 32-bit interface should be deprecated but not
removed.
If a file of more that 2^31 (or maybe 2^32) bytes is accessed
via the 32-bit API, the operation should be faulted if it's
inappropriate.
There are some file operations that are size neutral, e.g.
sequential read or write byte or block, so there's no need to
fault them or deprecate them.
How are we doing so far?
Dave
---
To alter your preferences or leave the group,
visit //www.freelists.org/list/iyonix-support
Other info via //www.freelists.org/webpage/iyonix-support
Other related posts:
