Filing system improvements (step 3)

I was reading the content of the bounty, and it occurs to me that since it mentions 64b file size, a new 64b API for FileSwitch should be mentioned in the list of deliverables.

Also, if BASIC applications are going to manipulate such files, then BASIC will need a 64 bit integer data type.

Not necessarily, on other platform and languages 64 bit file sizes were around a long time before 64 bit data types, you just had to work with the lower and upper parts.

Not necessarily, on other platform and languages 64 bit file sizes were around a long time before 64 bit data types, you just had to work with the lower and upper parts.

Indeed so.

As you would still have to do were a 64-bit interface introduced for RISC OS filesystems – we only have 32-bit registers to pass data in and out of SWIs.

There may be ways of making life easier with BASIC – for example PTR#f%% could call a 64-bit API and return a 64-bit value. EXT#f%%,ext% might give a helpful error as you aren’t passing wide enough data, whereas of course BPUT#f%%,char% would be fine.

I did have a look at the innards of Fileswitch a few years ago and thought that a 64-bit interface could be added without perturbing it too much. In the GBPB routines for example, R4 is always used as the current file pointer. If one were to change R4 internally to be a pointer to a 64-bit file pointer, that’d save a lot of upheaval trying to find spare registers. Rather than using R4 directly for calculations, just pass it to SUBIND64, CMPIND64 … routines.

On entry to a 32-bit call, dump a zero and caller R4 on the stack, set R4 to be a pointer to that.

On entry to a 64-bit call, dump caller Rhi and caller R4 on the stack, set R4 to be a pointer to that.

Reverse for exit.

Fileswitch just then has to worry about calling filesystems that haven’t registered themselves as having a 64-bit interface.

[Edit: I personally don’t think that it’s a sensible move to try to adapt FileCore to a radically different format. We talk about FileCore format discs, which are evolutions of the original ADFS format. You couldn’t call ext4 ‘FileCore format’. Make a new module without any of the existing (I hesitate to say) accumulated cruft, e.g. Ext4Core. Low-level drivers (which the bounty acknowledges would need updating) would then first try registering with NewShinyCore then fallback to FileCore if NewShinyCore isn’t interested.]