On Saturday, 9 May 2015 at 12:16:58 UTC, Kagamin wrote:
On Thursday, 7 May 2015 at 16:04:56 UTC, Jens Bauer wrote:
Regarding (1), because marking a variable 'shared' is not
enough (it allows instructions to be moved around), Johannes
already made a volatileLoad and volatileStore, which will be
usable for microcontrollers, though for convenience, it
requires writing additional code.
-But this solution ... I do not know if it would work, when
writing a driver for Debian running on a i586 platform or
PowerMac G3 for instance.
System calls on sufficiently smart processors like x86 use
C-like ABI good practices: registers and buffers to pass data
instead of global variables, because multithreaded programs
will have race condition on accessing the global variables. See
read(2) syscall as an example of such API
http://man7.org/linux/man-pages/man2/read.2.html
To make my question a little clearer: This part is not about RAM
locations, but I/O-memory locations AKA. hardware addresses.
On some systems, such as the 68xxx based Atari and Amiga,
peripherals are accessed by reading and writing to memory
locations; those locations are addresses belonging to hardware;
eg. "hardware space". This depends on the CPU.
As an example, the Atari, the address space was usually
0x..ffxxxx, where the first two dots were "don't care", as the
68000 was only 24-bit; later, 0x00fxxxxx was mirrored to
0xfffxxxxx, for backwards compatibility.
Thus the address space between 0x..f00000 and 0x..ffffff was not
ordinary RAM, but I/O-space.
On Z80, for instance, it's common to use the IN and OUT
instructions to access hardware, so normally you wouldn't use
precious memory locations for peripherals on such systems.
... "System calls" will need to access the peripherals in some
way, in order to send data to for instance a printer or harddisk.
If the way it's done is using a memory location, then it's
necessary to tell the compiler that this is not ordinary memory,
but I/O-memory AKA hardware address space.
On Thursday, 7 May 2015 at 18:18:02 UTC, Johannes Pfau wrote:
Not sure about shared (I don't think anybody knows what
exactly shared is supposed to do)
Shared is supposed to prevent the programmer from accidentally
putting unshared data in a shared context. Expectedly people
wanted it to be a silver bullet for concurrency, instead
std.concurrency provides high-level concurrency safety.
In other words, it's the oposite of 'static' ?
-If so, then that makes the purpose much clearer to me, and it
absolutely makes sense. :)
... Like the "export <symbol>" or "xdef <symbol>" directives in
assembly language.
