inlineC float byVal & byRef working example

You are reading a single comment by @d3nd3-o0 and its replies. Click here to read the full conversation.

•

d3nd3-o0
It could be that getAddressOf(var,true) does not properly do what its described it does? Because it does not return 0 when an apparent non flatstring based flat ArrayBuffer is given to it.

Mb its wrong to assume that all Int32Array etc are flat, cos if you give small length, its not?
```
["flatAddress","bool","(boolean) If `true` and a Flat String or Flat ArrayBuffer is supplied, return the address of the data inside it - otherwise 0. If `false` (the default) return the address of the JsVar itself."]
```
Unless I am missing some information about flat array buffers, perhaps it does not refer to the underlying buffer...

That is why I didn't think about flatstring being the culprit for so longer, was so happy checking the return value of E.getAddressOf(). Perhaps it only applies to strings?
```
E.toString() notes ->
You can still check if the returned value is a Flat string using E.getAddressOf(str, true)!=0, or can use E.toFlatString instead.
```
The reason it was important for this to work with RAM Upload was because that is how I test most of my development, I didn't want to make LOADS of writes to the flash just when i am debugging my code.

•

fanoush in reply to @d3nd3-o0
It could be that getAddressOf(var,true) does not properly do what its described it does?

Maybe. It returns address if it makes sense = data is stored in one block, even normal short string can have the data in one block
https://github.com/espruino/Espruino/blob/5f6ad65e8c8bd51a2c1be17fe68ee162ce4e8c88/src/jsvar.c#L1745

This is also the case for your array
```
>var f=new Float32Array(1)
=new Float32Array(1)
>E.getAddressOf(f.buffer,true)
=536895915
>peek32(536895915)
=0
>f[0]=0.5
=0.5
>peek32(536895915).toString(16)
="3f000000"
>f[0]=0.25
=0.25
>peek32(536895915).toString(16)
="3e800000"
>trace(f)
#832[r1,l1] Float32Array (offs 0, len 1)  #828[r1,l0] ArrayBuffer (offs 0, len 4)    #844[r1,l0] String [1 blocks] "\0\0\x80>"
=undefined
```
It can be seen the float array is backed by short string that takes up single block so it is makes sense to get the address of it.

However you can see that in my case the address is not aligned (ends with 5) so reading or writing float value from/to FPU register with such pointer will crash on unaligned memory access.

see also https://stackoverflow.com/questions/63834136/how-to-avoid-unaligned-access-exceptions-with-float-on-cortex-m4

About

Avatar for d3nd3-o0 @d3nd3-o0 started