World: r3wp

Adding to this, pointer! can also be used for type casting (following 
AS keyword).

Is that typecast changing the integer to a c-string! (a kind of pointer 
to byte), or is it changing the pointer to the integer to a c-string!?

It seems to me that the latter would be:
    s: as c-string! c

In the example from 4.6.6, c/value refer to the pointed integer value, 
so it is the former, integer! -> c-string! (== pointer! [byte!])

Exactly.

I might have been inspired by your ticket (I remember vaguely reading 
it a long time ago). Using AS for type casting, was a natural extension 
of the as-string / as-binary syntax from R2.

As was the ticket. Remember that in Red proper, AS should do conversions, 
not casting, for safety. Given all this typecasting, it is looking 
more and more like Red proper should have the handle! type instead 
of pointers, where a handle! would be a pointer-like thing with no 
dereferencing, arithmetic, or value setting or getting in Red itself. 
Then let Red/System cast the handle! to whatever pointer type it 
needs to.

And then back to a handle! if it's going to be passed back to Red 
code.

Pardon my mistake if you weren't thinking of Red/System as being 
a bit like unsafe code sections in C#, JNI code in Java, or extensions 
in R3.

Yes, that is a good option. Red has to be safe, that's one of the 
main reason for having Red/System dialect.

No mistake, that is a correct way to see the separation between Red 
and Red/System.

Cool. That will allow us to reuse some of the the reasoning about 
code that has been made about those situations in other languages, 
and tweak the model to learn from their lessons.

Precisely. :-)

I was thinking about struct parameters to functions. If C doesn't 
allow struct parameters and return values, only struct references 
or pointers, then Red should follow that model when declaring functions 
with the cdecl calling convention, and similar restrictions for stdcall, 
fastcall, etc. Then when we need to support other calling conventions 
that do support passing actual structs as parameters, we can just 
add to the list (pascal or Delphi, for instance).

I haven't had a chance to look yet... Does the revised struct model 
support seeing pointers as equivalent to references to structs with 
one member?

Implicitly, yes.

Calling convention: adding new ones shouldn't require much work (unless 
they are very exotic).

BTW, I was thinking these last days that I maybe should allocate 
a week before starting the work on Red's compiler, to implement an 
experimental JVM bytecode emitter (and a .class file format). The 
reason for that is to have a 2nd emitter (in addition to IA32) that 
is addressing a very different architecture. This should help make 
a cleaner abstraction layer for upcoming emitters (especially those 
not written by me).

I might alternatively pick up CLR for that task, thought (less work 
for the file format as it is basically PE).

A good calling convention to add would be JNI, for Java and Dalvik 
code. We would have to reverse-engineer the behavior of the C macros 
and types that implement this in the JDK and NDK.

This should help make a cleaner abstraction layer

 To be more accurate, I think the current one is OK, but it will certainly 
 need some tweaking when a 2nd emitter will be added, so better tweak 
 it sooner than later.

Brian: what about JNA? Isn't that interface better than JNI?

Never heard of JNA. Java and Dalvik both use JNI.

http://en.wikipedia.org/wiki/Java_Native_Access

Sounds interesting. Is it an addon that can be used on a standard 
JVM? I'll look it over later, especially to see if Dalvik supports 
it.

I tested the new section headers on Syllable Desktop. We're a step 
further, but it doesn't work yet. It doesn't complain about them 
missing anymore, but about read-only and write sections overlapping, 
which our loader doesn't support, if I remember correctly

This is from the kernel log:

0:bash::bash : memmap_instance() RO overlap RW (08048000 + 00001000 
-> 08048000)

0:bash::bash : ERROR : execve(./hello) failed. Too late to recover, 
will exit

Kaj: thanks for the report. I thought we were cleanly separating 
RO and RW sections in two different LOAD segments...maybe the flags 
are not correctly set in sections (or in section headers). I'll give 
it a look this weekend if Andreas has not the time to fix it before.

It's quite possible that the format is correct, but that the Syllable 
loader doesn't support it. It does work on Linux (although that may 
not use the section headers at all)

I remember that we had a similar problem many years ago when the 
standard GNU software that we incorporate started generating such 
a construct in new versions of the toolchain. I think our solution 
was a quick hack, so on the one hand we can load a lot of current 
software, but on the other hand it is also fairly easy to upset our 
loader

It is also possible that other adaptations need to be made to the 
format. Syllable can load Linux binary dynamic libraries if the dependencies 
are not Linux specific, but it can't load Linux binary program executables 
as far as I know - which we are trying now. There are subtle differences 
in their configurations, which we may need to adjust for

Maybe the most obvious difference: it looks like the Red output uses 
the common TEXT_START_ADDR=0x08048000 while Syllable uses TEXT_START_ADDR=0x80000000

Syllable maps the kernel into the first half of the address range. 
Programs are supposed to go into the upper half, but a Linux executable 
probably tries to map itself into Syllable's kernel area

Could you try changing the base address in ELF.r? It is a the top 
of the file:
context [
	defs: [
		image [
			base-address	134512640	; #{08048000}
		]

Thanks, I will

-= Red/System Compiler =- 
Compiling /resources/Red/tests/hello.reds ...
660
** Math Error: Math or number overflow
** Where: resolve-symbol-refs
** Near: pointer/value: data-ptr + spec/2 
foreach
>>

Using 2147483648  ; #{80000000}

What about using R3?

For what?

64 bits?

yes

I'd be pleased with that, but structs do nothing in R3

ah.. so that will be a problem I guess.

The struct is used in RED only for the syntax or something else as 
well? It would be quite easy to create an extension maybe.

Anyway, 32 bits targets still require 32 bits arithmetic

Continuing from !REBOL3:


When defining a minimum set of natives for a REBOL like language, 
at one point you have to consider ADD vs. +. If you have the + operator, 
you can create ADD as a function. On the other hand, if you can create 
your own operators (which isn't possible in REBOL), you could make 
+ from ADD. So which one is more basic? Are both justified?

Depends on whether the point of view is grammar or semantics

In a functional language, infix operators are usually considered 
syntax sugar. On the other hand, in Red/System, + is elementary

Ok, make sense. So the answer kinda depends on whether you consider 
the language strictly functional maybe?