World: r3wp

Just a question towards the RED possible performance. Are all RED 
natives going to be implemented in Red/System? There might be possible 
cases, where RED is going to be slower than REBOL, no? E.g. SORT 
- in REBOL, it goes directly to the C level. If RED compiles to RED/System, 
and SORT is going to be written in RED/System, which will be surely 
slower than C, then there will be cases, when RED is slower than 
REBOL? Well, we might as well implement SORT or math intensive stuff 
in C directly, as kind of cross-platform lib, and pass it over, but 
then such a library would have to be compiled for all platforms ...

Once we'll work on optimizing Red, we'll use the fastest routines 
available for critical code parts. For SORT, I'm not sure it will 
be slower, but if it's the case, we'll use the C version.

I mean we'll use qsort() if faster than the equivalent in Red/System. 
Building a runtime lib in C for Red is not necessary, that would 
defeat one of the purpose of Red/System.

if I were to use SOURCE on a native! in Red, would it show the actual 
source?

Watching your floating point support, another question - is it possible 
(later) for Red/System to evelve into general C wrapper? I mean - 
that I would not need to use C, but Red/System, maybe plus inlined 
C/ASM, having math operations including floats? But maybe that's 
not Red/System intended purpose even in the long run?

As I understand it, the priority is to support such features in Red/System 
recently, to allow 1) wrapping of external libraries 2) provide enough 
of ground for RED itself to be compiled into ...

Red/System has supported that from the start

The point of developing an own low level language with an own compiler 
is to not need C and a C compiler. Which is something we can use 
very well in Syllable, for example

RED/System, which will be surely slower than C.


There's no reason for that to be necessarily the case. Red/System 
is a compiled, low-level language; at the very same level as C.

And as Kaj already said as well, Red/System is actually not only 
to "evolve into general C wrapper?", it is meant to actually replace 
C (for some purposes). Red/System aims to interface nicely with native 
libraries (which are, more often than not, created by using C).

The only reason that Red/System would be slower than C would be if 
the C optimizer were better than the Red/System optimizer. The languages 
have similar semantic models and are implemented similarly - they 
are in the same class, more or less.

I can only hope that Red's SORT will be more correct than the one 
in R3, which has known bugs :(

It will be slower in average especialy for looping intensive computations 
like the sorting algorithms. I don't think the Red compiler can remain 
simple and beat a full featured optimizing c compiler.

The simple current compiler technique used by Red (variable pushed/poped 
 on the stack ) is already easly beaten by any c compiler.

Any C compiler with a register allocator, that is :)

obviously ;-)

Yes, there are C compilers that don't care :)

TCC for example, if I'm not mistaken.

TCC is for science not for business :)

Don't say that :) TCC has many obscure uses :)

Steeve: certainly, but as you might have noticed, Red/System current 
implementation is a bootstrap for the Red/System future version written 
in Red. So all the current Red/System code written in REBOL, will 
be trashed once Red will be mature enough. Adding heavy optimizations 
at this point would be just a waste of time and energy that would 
serve no purpose.

For example, supporting fastcall calling convention and having a 
good register allocator are part of the optimizations that will be 
added when Red/System will be rewritten. Also, the internal compiler 
architecture, especially the code emitter will be quite different 
from the current one. I plan to introduce an intermediary representation 
and an internal event-based API. The various optimizations should 
be added as plugins/modules to the compiler, allowing to "hook" at 
various different stages of the compilation process. Also, this "API" 
should be partially (or fully) exposed at Red level, allowing to 
"easily" write Red & Red/System compiler extensions if needed.

Public service announcement: it's "Red", not "RED". Thanks for listening 
:)

I think RED is a registered trademark.

(anyway)

Thanks. :-)

Doc, would you be interested in getting BeagleBone for the kind of 
experiments? See links group for more info. IMO embedded & mobile 
should be Red's target ...

I'm interested in a board that would require 500mV for running as 
it seems to be the limit for the small solar panel + battery, I've 
ordered for powering my Arduino.

Also, I will get my hands on the Raspberry first, we'll see for others 
after that. (I admit that the BeagleBone boars specs are seducing 
too)

Arduion can't run full operating system imo. I found it underpowered, 
but maybe enough for home automation.

Arduino with AVR 32-bit MCU can, there are Linux versions running 
on it.

Can't find the links about that anymore, I wonder if I haven't confuse 
that with another board?

Found one at least: http://www.indefia.com/products/hardware/emblinux/

The main link leads to an almost empty page: http://avr32linux.org
(looks like they are recovering from a crash)

As for ARM CPU support, I will have to rescan this group, about what's 
supported. We have one dev board with Cortex-M3

In order for Red to appear on the Tiobe Index, one requirement is 
to have an entry on (english) Wikipedia, clearly describing it as 
a programming language, as explained here: http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm


I have contacted Tiobe and they are ok for including Red when this 
requirement will be fulfilled. If someone here is willing to do it, 
that would really help boost Red's visibility. That is typicaly something 
that I cannot do myself, it would go against Wikipedia's rules.

Cortex-M3: Andreas mentioned that it requires the Thumb2 instruction 
set, so, it won't work with the current Red ARM backend.

If there's is a corresponding instruction in Thumb2 for each one 
we currently use in the ARM backend, a new port could be quickly 
made (but don't expect me working on this one in the next months, 
it's too low priority).

that's ok ....

We support ARMv5+ at the moment. So that means ARM9E, ARM10E, XScale, 
ARM11, Cortex-A based cores should work fine. Most notably, Cortex-M 
won't (as those cores only support the Thumb instruction set). Neither 
will StrongARM (which is ARMv4).

thanks ...

I have a rather nice Cortex-M3 based board lying around as well. 
So maybe I'll get around to tackle the Thumb profile some day :)

Doc - what layer will be e.g. events implemented in? Red/System, 
or Red? I mean - will you use your own implementation, or will you 
adopt some libraries for concurrency, events, e.g. libevent, liboop, 
etc.?

We'll start simple, so implement our own internal event loop which 
will have a Red/System backend and a frontend at Red level, probably 
following the R3 port model.

I don't see the necessity for an external lib for concurrency or 
events management, when the OS are already providing everything we 
need (I guess that pthread lib is standard part of Linux now?).

Float support so far:

---
Red/System [ ]

#import [
	LIBC-file cdecl [
		cos: "cos" [
			x 		[float!]
			return: [float!]
		]
	]
]

pi: 3.14159265358979
printf ["%.14f" cos pi]
---

outputs: -1.00000000000000

The only drawback for now is that 64-bit values break the typed/variadic 
stack layout (meant for 32-bit values only). I need to find a workaround 
for that.

So, currently PRINT and PRINT-WIDE can't be used with floats.

(I haven't pushed the float branch yet, I still need to improve this 
first version)

PThreads are the native Linux threads implementation for a number 
of years