string to char array?

[Kyoji Klyden via Digitalmars-d-learn]

On Saturday, 6 June 2015 at 10:12:54 UTC, Marc Schütz wrote:
>> ...
>
> Almost correct :-) The part of "has nothing left, so go back" 
> is wrong. The call to _d_arraybounds doesn't return, because it 
> throws an Error.
>
>> ...
>
> Yes, inside the `f` function, the compiler cannot know the 
> length of the array during compilation. To keep you from 
> accidentally accessing invalid memory (e.g. if the array has 
> only two elements, but you're trying to access the third), it 
> automatically inserts a check, and calls that runtime helper 
> function to throw an Error if the check fails. .L.str is most 
> likely the address of the error message or filename, and 55 is 
> its length. The 5/6/7 values are the respective line numbers. 
> You can disable this behaviour by compiling with `dmd 
> -boundscheck=off`.
>

Thanks for the reply!

so I'm a tad unsure of what exactly is happening in this asm, 
mainly because I'm only roughly familiar with x86 instruction set.

_d_arraybounds throws an error because it can't access the 
runtime? or because as you said the compiler can't know the 
length of the array?

for .L.str, 55 is the length of the address..?


>> Also in the mov parts, is that moving 1 into the pointer or 
>> into the rsi register? And is rsi + 4, still in rsi, or does 
>> it move to a different register?
>
> It stores the `1` into the memory pointed to by `rsi`, or 
> `rsi+4` etc. This is what the brackets [...] mean. Because it's 
> an array of ints, and ints are 4 bytes in size, [rsi] is the 
> first element, [rsi+4] the second, and [rsi+8] the third. 
> `rsi+4` is just a temporary value that is only used during the 
> store, it's not saved into a (named) register. This is a 
> peculiarity of the x86 processors; they allow quite complex 
> address calculations for memory accesses.

Does the address just get calculated whenever the program using 
this asm, then? :o