Dare I ... another volatile discussion ?

Jens Bauer via Digitalmars-d digitalmars-d at puremagic.com
Sat May 9 09:59:34 PDT 2015


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.


More information about the Digitalmars-d mailing list