OS_Convert of long longs

There are some SWI numbers allocated (and appear in the name <=> number table) but that aren’t implemented that I want to use.
OS_ConvertHex16, OS_ConvertCardinal8, etc…

Before implementing them, any idea how best to pass in the 64 bit number? Pass it in R3, or use R0 as a pointer to a block of 2 words (a la DiscOp64).

Infact, since they’ve never been implemented could they be changed to OS_ConvertThingN where N is passed in a register rather than proliferating SWI numbers – there aren’t that many left below &100.

Infact, since they’ve never been implemented could they be changed to OS_ConvertThingN where N is passed in a register rather than proliferating SWI numbers

That sounds fine to me. If you went with that approach, it would also make sense to use a buffer to store the result rather than registers (since the algorithm might end up being used for very large ‘N’ values)

Seconded on Jeffrey’s suggestion. Clearly, it would need to return with suitable X-bit-set errors for various problem cases (presumably the only one likely is insufficient space in the supplied buffer). Maybe there’d be a mode where you pass in zero and zero as the buffer pointer and size in order to request the estimated buffer requirements?

Well if we’re all pretty relaxed about deviating from the spirit of the existing OS_Convert family I’m tempted to ditch the currently reserved block and just go with a single SWI. This would free up SWIs &EE-&F4 and just use &ED.

SWI OS_ConvertNBytesOfInputStuffToSomeOtherStuff (or more catchy name)
R0 = ptr to buffer for input values
R1 = ptr to buffer for the result
R2 = size of result buffer
R3 = value of N
R4 = conversion to perform (one of hex; Cardinal; Integer; Binary; SpacedCardinal; SpacedInteger; FixedFileSize; FileSize)

on exit
R0 = value of R1 on entry
R1 = pointer to null terminator
R2 = free bytes in buffer

If R2 is -ve on entry, R2 returns minus the space needed for conversion (like OS_ReadVarVal).
Maybe limit the value of N to 16 bytes or something? That allows for uint128_t.

I did get a bit confused between OS_ConvertXXX and OS_ReadXXX there. What I meant to say was, to use a buffer for the input number, so the SWI can be extended to cope with numbers larger than 2^64 should the need arise (Edit – Although it looks like everyone’s managed to work out what I meant anyway).

Steve’s idea about allowing the required destination buffer size to be read makes sense as well.

I suppose this API will need to define the possible error codes, of which I can foresee maybe three:

1. buffer too small
2. unsupported conversion
3. invalid number (e.g. one day it might take floating point input values or something which can contain a NaN)

Sounds like a plan. Need a competition for the name: OS_ConvertMultipleN is all I can come up with (vaguely fitting the OS_ConvertCardinal4 pattern). Or OS_ConvertVariedVaried…

How about the simplest possible: OS_Convert?

OS_GenericConvert

R4 = conversion to perform

So I’ve come up with

• Hex
• Hex in lower case
• Binary
• Cardinal
• Integer
• Grouped cardinal (space every 000)
• Grouped integer (space every 000)
• Punctuated cardinal (comma or full stop every 000 depending on Territory)
• Punctuated integer (comma or full stop every 000 depending on Territory)
• EUI (for MAC addresses and EUI64 etc)
• IPv4 dotted address
• IPv6 colon address
• IPv6 colon address shortened per RFC5952
• File size (up to 4 digits plus SI suffix)
• Fixed file size (same, but prepadded with spaces)

Have I missed anything obvious? I’m conciously not trying to just make it like printf(), but thinking what common integer conversions modules frequently need to do to present numbers to humans.

comma or full stop every 000 depending on Territory

Or a space.

Or a space.

Well, yes, whatever the Territory Manager says would be used.