Architecture tagging for EEPROMs - feedback requested

[Solra Bizna 10]

EEPROMs do not currently have a means of targeting a specific architecture. All of the OC-ARM EEPROMs I've made have had the following structure:

--[==[actual program data goes in here]==]error"This EEPROM is not compatible with Lua computers"

My ROM mapping code "skips" any --[ followed by zero or more = followed by another [ in the EEPROM. This solution avoids the problem of loading an OC-ARM EEPROM in a Lua computer, but not any other combination. It also takes away 65 bytes that could otherwise be used by the program.

I think we need a more general strategy for architecture-specific ROMs. One way to handle this would be to add a "na" (short for Need Architecture) function to machine.lua, and have non-Lua architecture EEPROMs take the exact form (with no extra spaces):

--[==[actual program data goes in here]==]na"Architecture Name"

Where there can be zero or more =, but the number of = must match on either side. (This allows the number of = to vary on an architecture by architecture or even program by program basis, as needed to prevent the comment from leaking.)

The na function could be as simple as:

function na(arch)
  error("This EEPROM requires a CPU running the "..arch.." architecture.")
end

This would prevent the Lua architecture from running out-of-architecture EEPROMs, without breaking any existing Lua EEPROMs. The na function might also try calling computer.setArchitecture and rebooting.

Other architectures would then parse the exact structure above, and check that the "Architecture Name" exactly matches their architecture. If it doesn't, they could crash with an error message equivalent to the above. If it does, they map the EEPROM, skipping as many bytes as are in the initial --[==[ block.

The "Architecture Name" would have to be standardized, to prevent problems. For instance, mine would likely be "OC-ARM", while the other ARM architecture might be "OpenArms".

I'd be happy to write this up as an OETF document, but first I'd like to hear how other architecture devs have handled this problem, and get feedback on this idea in general.

[Gorzoid 10]

or just give EEPROM's a seperate nbt tag saying what architecture it is for. and the CPU won't run EEPROM's from different architectures

[GreaseMonkey 7]

I prefer the NBT tag approach, and it could possibly have a list of architectures it can handle (e.g. it could be tagged "Lua 5.2;Lua 5.3") and if it doesn't handle the given arch the CPU can autoswitch to the first available arch in the list.

[Solra Bizna 10]

The only downside of that is that the "flash" utility would have to prompt for that information (user error party!), or it would have to be stored in the ROM file some other way. I'm open to it, though.

Perhaps something like my original proposal as the storage format, and the "flash" utility can recognize that, strip it, and tag the EEPROM? ROM images that aren't tagged would default to "Lua 5.2;Lua 5.3" for obvious reasons.

Maybe something like:

 

arch=Lua 5.2;Lua 5.3
Blah blah blah

and after "flash" is done with it, the EEPROM only contains "Blah blah blah" and has its architecture tag set to "Lua 5.2;Lua 5.3".

I like any solution that enables auto-switching of architectures, and at the same time I don't. (I think like wins out, though.)