riscv/musl - musl - Gitea: Git with a cup of tea

2611 Commits

2 Branches

78 Tags

7.6 MiB

Tree: 1312930f9b

Commit Graph

Author	SHA1	Message	Date
Rich Felker	cec33b2c60	fix or1k atomic store at the very least, a compiler barrier is required no matter what, and that was missing. current or1k implementations have strong ordering, but this is not guaranteed as part of the ISA, so some sort of synchronizing operation is necessary. in principle we should use l.msync, but due to misinterpretation of the spec, it was wrongly treated as an optional instruction and is not supported by some implementations. if future kernels trap it and treat it as a nop (rather than illegal instruction) when the hardware/emulator does not support it, we could consider using it. in the absence of l.msync support, the l.lwa/l.swa instructions, which are specified to have a built-in l.msync, need to be used. the easiest way to use them to implement atomic store is to perform an atomic swap and throw away the result. using compare-and-swap would be lighter, and would probably be sufficient for all actual usage cases, but checking this is difficult and error-prone: with store implemented in terms of swap, it's guaranteed that, when another atomic operation is performed at the same time as the store, either the result of the store followed by the other operation, or just the store (clobbering the other operation's result) is seen. if store were implemented in terms of cas, there are cases where this invariant would fail to hold, and we would need detailed rules for the situations in which the store operation is well-defined.	12 years ago
Stefan Kristiansson	200d15479c	add or1k (OpenRISC 1000) architecture port With the exception of a fenv implementation, the port is fully featured. The port has been tested in or1ksim, the golden reference functional simulator for OpenRISC 1000. It passes all libc-test tests (except the math tests that requires a fenv implementation). The port assumes an or1k implementation that has support for atomic instructions (l.lwa/l.swa). Although it passes all the libc-test tests, the port is still in an experimental state, and has yet experienced very little 'real-world' use.	12 years ago

Author

SHA1

Message

Date

Rich Felker

cec33b2c60

fix or1k atomic store

at the very least, a compiler barrier is required no matter what, and
that was missing. current or1k implementations have strong ordering,
but this is not guaranteed as part of the ISA, so some sort of
synchronizing operation is necessary.

in principle we should use l.msync, but due to misinterpretation of
the spec, it was wrongly treated as an optional instruction and is not
supported by some implementations. if future kernels trap it and treat
it as a nop (rather than illegal instruction) when the
hardware/emulator does not support it, we could consider using it.

in the absence of l.msync support, the l.lwa/l.swa instructions, which
are specified to have a built-in l.msync, need to be used. the easiest
way to use them to implement atomic store is to perform an atomic swap
and throw away the result. using compare-and-swap would be lighter,
and would probably be sufficient for all actual usage cases, but
checking this is difficult and error-prone:

with store implemented in terms of swap, it's guaranteed that, when
another atomic operation is performed at the same time as the store,
either the result of the store followed by the other operation, or
just the store (clobbering the other operation's result) is seen. if
store were implemented in terms of cas, there are cases where this
invariant would fail to hold, and we would need detailed rules for the
situations in which the store operation is well-defined.

12 years ago

Stefan Kristiansson

200d15479c

add or1k (OpenRISC 1000) architecture port

With the exception of a fenv implementation, the port is fully featured.
The port has been tested in or1ksim, the golden reference functional
simulator for OpenRISC 1000.
It passes all libc-test tests (except the math tests that
requires a fenv implementation).

The port assumes an or1k implementation that has support for
atomic instructions (l.lwa/l.swa).

Although it passes all the libc-test tests, the port is still
in an experimental state, and has yet experienced very little
'real-world' use.

12 years ago

2 Commits (1312930f9bdea47006a8a8c8509c0bed5cf69e85)