World: r3wp

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?

Another function is the math EXP function. It just raises the number 
e to some power (the argument). A language like C (and probably most 
others languages) has this function (in the math library though). 
Probably to make code faster, but it can easily be defined as a REBOL 
function, right?

There are some rounding problems though, so it maybe can't be made 
easily, but probably using a trick.

>> exp 1
== 2.71828182845905
>> myexp: func [v] [2.71828182845905 ** v]
>> myexp 32
== 78962960182685.1
>> exp 32
== 78962960182680.6

So we might need more digits for e.

you know, I was half joking when I suggested this group... :-)

:) well, it's a good group for this, as Doc would consider these 
things at some point.

I just woudn't want it to take over the topical discussions related 
to actual Red implementation and use.

>> myexp: func [v] [2.7182818284590451 ** v]
>> myexp 32
== 78962960182680.6
>> exp 32
== 78962960182680.6

With 2 extra digits, it seems to work.

With e defined, the hyperbolic cos, sin, tan, etc. are easy (REBOL 
doesn't have these), and maybe also normal cos, sin, tan!? At least 
for complex numbers, but not so sure about reals. Maybe a better 
mathematician can tell us that? Ladislav?

John, in a real REBOL-like language + is implemented using ADD; all 
operators redirect to their associated functions. You could do a 
similar trick with a compiled REBOL-like language like Red. This 
brings up another question though: Will Red implement operators in 
a fixed-predefined-set way like R2, or in a user-defineable way like 
R3? I hope the latter, though the former would make sense for Red/System, 
at least in the pre-Red stage of its development.

Are complex numbers considered in Red?

User-defined operators are really nice, I think. Being able to write 
things like:

remove 42 from [1 2 3 42 177 280]

where FROM is just a simple FIND.

but as an operator.

that is really nice geomol

For now in R3 there are some restrictions about the kind of functions 
you can make an operator from - number of arguments and such. It 
is planned to eventually relax one of the restrictions, and allow 
function!, closure! and command! functions to be used. However, even 
in Red there will likely need to be a fixed format to the arguments 
of such a function: 2 args with no refinements, the first arg corresponding 
to the left side and the second arg corresponding to the right.

To make a FROM op you would need to make a FROM~ wrapper function 
around FIND; you wouldn't be able to make an op from FIND directly.

there could be various forms to the ops.  there can be a way to tell 
the op building process to be unary binary or ternary.

Yeah, operators with only 2 arguments sounds like a good idea. More 
and it fastly become too complex leading to confusion.

f

fastly
 :-D Think "quickly"

brian, can we already build the FROM as an op in R3?  I've tried 
using the to-op and I can never get it to work.

(though we should go back to REBOL3! group)

Maybe NOT can be defined as a function this way?


not: func [value][either none = :value or (false = :value) [true][false]]

Will Red implement operators in a fixed-predefined-set way like R2, 
or in a user-defineable way like R3?

 Op! will be user-defined as they were in R-sharp interpreter. Here's 
 a short extract of R-sharp's boot script:

+:  make op! :add
-:  make op! :subtract
*:  make op! :multiply
/:  make op! :divide
=:  make op! :equal?
<>: make op! :not-equal?

This would be safer to do in Red than it currently is in R3 because 
the compiler can perform all of the evaluation safety checks as part 
of its type checking, with no runtime overhead.

Exactly, safer and cheaper to do with a compiler.