TIC-80 WebAssembly: pointers to fixed addresses

Adam Ruppe destructionator at gmail.com
Sat Apr 16 20:36:12 UTC 2022


On Saturday, 16 April 2022 at 14:29:09 UTC, Pierce Ng wrote:
> ```
> pub const FRAMEBUFFER: *allowzero volatile [16320]u8 = 
> @intToPtr(*allowzero volatile [16320]u8, 0);
> pub const TILES : *[8192]u8 = @intToPtr(*[8192]u8, 0x4000);
> pub const SPRITES : *[8192]u8 = @intToPtr(*[8192]u8, 0x6000);
> ```
>
> I believe the above is declaring that FRAMEBUFFER is a pointer 
> to 16320 (sic) bytes starting at address 0, TILES is a pointer 
> to 8192 bytes starting at address 0x4000, and SPRITES a pointer 
> to 8192 bytes starting at address 0x6000.
>
> Currently for D I have the following, copying the D binding for 
> Wasm4, another fantasy console:
>
> ```
> const FRAMEBUFFER = cast(uint*)0;
> const TILES = cast(uint*)0x4000;
> const SPRITES = cast(uint*)0x6000;
> ```
>
> How to express in D, similarly to Zig, that FRAMEBUFFER refers 
> to a byte[16384] array starting from address zero, and so on?

Take the pointer and slice the pointer:

__gshared ubyte[] framebuffer = (cast(uint*) 0) [0 .. 16320]; // 
gshared cuz otherwise D assumes it is TLS and it isn't


Now you can notice it isn't const. You don't want it const since  
the point is to write to the thing. What you might do to keep the 
pointer itself from ever changing is to make it a property:


ubyte[] framebuffer() { return (cast(uint*) 0) [0 .. 16320]; }


And the compiler will see how trivial that is and inline it so it 
works the same way, but then nobody can ever rebind the 
framebuffer symbol.


More information about the Digitalmars-d-learn mailing list