World: r4wp

It's basically unrelated to Thumb. It's not necessarily about hardware 
floating point, either, but it's a different way of supporting it

It's about dealing with different Linux kernel incompatible ABI for 
float support on ARM platforms. Red/System uses the FPU unit (named 
VFP in ARM family) directly, but when having to pass/receive float 
arguments from libc or 3rd-party libs, Red/System needs to do it 
respecting the installed system ABI, which might be `softfp` or `hardfp` 
(there's a third one, but it's for not a concern for us). 


Currently, Red/System floats are passed using the `softfp` convention, 
so it works only on ARMEL platforms (while ARMHF platforms require 
`hardfp` convention). `hardfp` is a much more performant, while `softfp` 
is for legacy  systems or systems with no FPU unit).

BTW, Red or Red/System apps that do not use floats seems to work 
well with both ABI.

So - lots of work to support ARMHF?

And also - do I need to know, which platform I need to support, or 
support can be in one exe, for both worlds?

You can't mix different ABI in one binary.

ARMHF: a little, it's the same work as the one done in IA-32 faster-float 
old branch. In a nutshell, it consists in passing float arguments 
in FPU registers directly instead of using the stack.

We'll provide compilation options and various additional targets 
to deal with those different ABI.

Are there different Android platforms as well?

AFAIK, Android libs uses softfp convention.

Same here, a little tour would be nice. (That is why I picked up 
a documentation check to start with). 

e.g. In actions.reds most of funtions are only present as 'name* 
and some are present as both 'name and 'name*

That was a reply to a post from Pekr from thursday 1.49 PM

Arnold: I certainly won't document nor make "little tour" for internal 
code that is in alpha stage. That would be just a waste of time. 
For the '* suffix for function names, it indicates that the function 
takes arguments from Red stack. But that might be changed in the 
future, like all the rest of the code...until we reach beta stage 
(or even until 1.0 release).

Yeah youre right. I will concentrate on other tasks preparing for 
propagating Red.

Fixed the math library in the C library binding; should now also 
work on OS X and Android

I simplified many of the bindings by using the new get-word functionality 
in Red/System 0.2.6 for getting the address of variables

I'm looking into the ARM callbacks issues you've reported.

Kaj: do you have a simple callback case that's failing on ARM and 
not using floats at all?

Hi Doc, did you plan to integrate some Open CL programming acces 
to Red in any future ? Here is a summary of kernel programming with 
OpenCL - and to me this seems accessible to Red, some day : http://www.manning.com/scarpino2/ch04sample.pdf
 for a larger picture summary of the beast here is the link to the 
book I referred to :  http://www.manning.com/scarpino2/(this is 
the Manning's publiaher deal of the day ,,, that's why I talk abotu 
this now). May be just a new binding and some extensions are required 
- but I would like to know more about the actual modifs required 
- when a small time is affordable for you to answer ?

OpenCL: yes, I have that in mind too, but it's most probably for 
a later version of Red (> v1.0). Also I have other plans to give 
Red access to GPGPU, by directly having a GPU machine code assembler 
and a dialect on top of it. It would be mainly for compiler internal 
use, but such dialect could be exposed for user code if some are 
willing to implement some fast GPU-powered routines.

If you're doubting about such approach, read this article:

 http://www.geeks3d.com/20110317/low-level-gpu-programming-the-future-of-game-development-on-pc/

Nice Doc, Thanks for taking time to answer. I'll "follow the guide" 
as we say here ! Have a nice day. Now I'll go reading  your link.

bOK Doc I agree for the speed factor But then you would do the multi-targets 
road again this time for multiple GPUs , isn't it ?

have to do ...

In between, here is the PyOpenCL lib link for those interested to 
see how the OpenCL API is accessed by other languages - and this 
could pave the way for some Red binding ... http://mathema.tician.de/software/pyopencl

OpenCL is certainly a quicker way to access it. My plan for direct 
GPU access is not only motivated by speed gains, but also by reducing 
complexity, having a simple, lightweight access to GPGPU capabilities.

Also, for direct GPU access, it will only be doable for GPU that 
have all the required specification published (unless drivers provides 
the right API already).

I know the french guy who used OpenCL to automatically parallelize 
some iterators for Scala, so it's definitely something I want to 
try for Red:
 
http://code.google.com/p/scalacl/

(I'm trying to compile Insight debugger on the RPi, compiling since 
half an hour...hope it will finish before tonight)

Ah, of course it ends up earlier with an obscure compilation error...

I haven't isolated any callback case yet, but the existing cases 
don't actively use floats

Thanks Doc - I know your way is the best you can choose for fine 
tuning GPU access without adding much overhead !

Kaj: I've pushed a fix for ARM that should improve the stability, 
can you do some quick tests to see if some of the issues are fixed?

cURL example script still crashing...

OK

I've added preliminary support for 64-bits integers to the SQLite 
binding. They're represented by a float! so they can be passed around, 
but they're hard to compute with

Ok, it seems we'll have to return to an explicit callback declaring 
syntax. In cURL, the callbacks passing (get-word! syntax) occur after 
the callback declaration, so when the compiler is creating the callback 
prolog, it has no way to guess that this particular function will 
be used as callback later....

We already have discussed this in the tracker, but I can't find the 
related tickets...

I also seem to remember this. Maybe it was the problem behind this:
https://github.com/dockimbel/Red/issues/204

#204: that's the one I would have loved to see documented ;-)

I think #193 might be the closest.

Ok, I think I see where lies the issue in the compiler.

The compiler is using two ways to encode the fact that a function 
is used as a callback:

- through the CDECL attribute presence (destined to be called by 
external code)

- through the internal CALLBACK flag that is assigned to all functions 
that get their pointer passed as argument (get-word! syntax).

Somewhere in the compiler, these two conventions are conflicting...let 
see if I can fix that without having to change anything to the current 
semantics.

Kaj: your code is ok, as long as it sets CDECL for marking functions 
called by external libs.

I should be doing that everywhere

Normally a function can't be used before it's defined. How could 
I pass a pointer to a function that's not defined yet?

It can if called from the body of another function.

(IIRC)

Function's body compilation is deferred. During global code compilation, 
only functions prototypes are collected, so all functions are known 
before the first function body gets processed.

That approach allow to solve cross-reference issues.