Add __UNALIGNED_UINT64_READ/WRITE

[kjbracey]

Extend unaligned access support macros to cover 64-bit accesses.

[kjbracey]

Lack of this became apparent in ARMmbed/mbed-os#12086

[JonatanAntoni]

@TTornblom, please cross check changes to IAR compiler header files.

[ghost]

Please update version and date in file header section of the changed files.

[kjbracey]

Please update version and date in file header section of the changed files.

Could you clarify the exact requirement here? It's not quite clear to me whether this is using per-file semantic versioning, or what. Can't find docs, and history seems inconsistent.

[JonatanAntoni]

Yes, history is extremely inconsistent. Ultimately what we need to assure is that someone who grabs only a single file from CMSIS still clearly knows from which version is was taken.

Hence I update at least the change date per file (see file header comments).

Additionally I increase the file version (on a per file basis) at least once per release on a semantic basis. For config files and user templates its even more important and the exact file version must be kept in sync with the pack description (ARM.CMSIS.pdsc).

You're absolutely right, we should think about putting a clear procedure to the docs. Where did you search for it?

[ghost]

Hello @kjbracey-arm,
all the CMSIS header files have a 'date' and a 'version' tag.
In my opinion these tags should be updated whenever changes are made to the file.

On the other hand it is not clear to me if these tags are necessary. It looks like they do not correspond to the CMSIS version to which the file belongs.

Maybe these tags can be removed from the file header.

What is the opinion of @JonatanAntoni on this?

[JonatanAntoni]

@GuentherMartin, I don't have a clear tendency.

On one hand maintaining these dates and versions manually is error prone. On the other hand people still tend to grab arbitrary versions of CMSIS files and start copying (redistributing) them around.

Ultimately some users come across problems in their version and raise issues here. Without a hint from which point in time the users version of a file was taken, it gets quite hard to recap the problems. In this case is helps to know at least the last modification date of each file. Perhaps that could be achieved somehow automatically?

[kjbracey]

Perhaps that could be achieved somehow automatically?

I don't think there's much you can do on a live Git repo to automate. The committer controls file content, and the repo doesn't get to mess with it. Any magic would need to be in a submitter-end hook (like the Change-Id thing that Gerrit uses).

An export via git archive can substitute $Date$-type markers in files. But that's not sufficient for people just grabbing stuff off GitHub clones.

Changes to these core files seem pretty infrequent, so probably reasonable to get submitters to manually update both date and semantic version on each.

If changes were frequent, you'd probably want to just do one semantic version update at release time.

Shall I do both date + version now?

[ghost]

If a file contains a date and a version tag then they should be updated if the file is changed.

A solution would be to use a 3 digit version like ..
If the file is changed 'patch' should be increased.
With a new CMSIS release 'CMSIS main' and 'CMSIS sub' are changed and 'patch' is reset to 0.

So everyone can clearly see to which CMSIS version a file belongs and if it is changed.

But I do not know how much effort this is or if this can be automated.

[kjbracey]

That proposal drops any possibility of final semantic versioning though. You could maintain metadata for changes on develop without having excess version changes on release by using a "pre-release" marker.

Eg
1.0.0 last release version
1.0.1-1 patch change on develop (increment patch version, and add pre-release marker)
1.0.1-2 another patch change on develop (increment pre-release only, no need to bump patch)
1.1.0-1 feature change on develop (bump minor, can reset minor and pre-release)
1.1.0-2 another feature or patch change on develop (increment pre-release only, no need to bump patch or feature)
1.1.0 next release version (remove pre-release marker)

That procedure is endorsed by https://semver.org/, generates the correct sort according to the "comparison" rules there. (1.0.1-1 < 1.0.1-2 and 1.1.0-1 < 1.1.0), and avoids any excess version increment on releases.

[JonatanAntoni]

@kjbracey-arm, on pack (and component) level we use semver as you described it. But I'd rather want to keep the "versioning" on file level simpler.

I think there is no value in updating all file version tags once per release only to reflect the component version in every file. In the beginning the file version reflected the component version to a certain extend. But we never maintained this kind of version information properly.

[kjbracey]

So just update the date on commit submission and leave it to you or other maintainer to do a file version change only on release? (According to maintainer's assessment of appropriate semver change or whatever?)

[JonatanAntoni]

In this case I'd update the file version of all files by doing minor+1 as its a backward compatible feature enhancement. Set the file change date to the submission date. Should be fine for now.

[kjbracey]

• Corrected error in IAR version
• Added to Core-A too
• Versions and date incremented

[JonatanAntoni]

@kjbracey-arm, would you mind to squash your commits into a single one?

[JonatanAntoni]

Can one of the admins verify this patch?