World: r3wp

i'll at least have a look or two :)

That would be cool

readelf gave me the impression that section and program headers are 
the same

Program headers describe segments. Segments are composed of one or 
several sections merged together. In our current ELF implementation, 
each segment contains only one section, so headers should be almost 
the same. That will change with the addition of dynamic linking support 
(which seem to require a lot of additional sections).

That could be the reason that our loader always expects segment headers, 
because a Syllable program is also a dynamic library

I think we ran into the multiple sections per segment problem halfway 
our development, when we needed to implement it

Wouldn't position-independent code be required even on Windows if 
you wanted to support address space layout randomization (ASLR) and 
other such tricks?

It also helps when running Windows code on fake Windows-like OSes 
like SanOS that load at a different address.

ASLR: I suppose it's required, but I can't find any information from 
an official source explaining the exact requirement for ASLR on Windows 
(except the additional flag to set in the executable header).


While searching for that, I found this interesting reading about 
PIC: http://www.gentoo.org/proj/en/hardened/pic-internals.xml#doc_chap7

I would like, if possible, to support PIC without the additional 
cost of an indirection table for global data.

Brian: loading at a different address should not be a problem, for 
that, relocatable code is sufficient. Full ASLR, however, will require 
not only relocatable but position-independent code.

(Take that with a sufficiently sized grain of salt, as I don't know 
anything about how ASLR on Windows works. But I find it hard to imagine 
how they would get away without PIC :)

But at least for PaX-based Linux ELF ASLR, full ASLR requires "position-independent 
executables" (PIE) which are  ELF binaries with a special type flag 
and PIC.

But I guess I wouldn't worry about ASLR for Red at this point :))

Interesting, it sounds like Syllable is prepared for that :-)

You have PaX on Syllable?

Some basic ASLR (stack randomisation and mmap-base randomisation) 
was added to the mainline Linux kernel in 2.6.12:
http://lwn.net/Articles/121845/

We don't have PaX, we have PIC executables, as far as I know

Beyond that, full ASLR is still quite rare in Linux, at least as 
far as I know.

New revision released: preprocessor replaced by a new one running 
at block-level (so much more accurate now). Includes and simple macros 
are now also possible.

Those are some good improvements

Includes make Red a real programming language :-)

Well, that's not my intention, but it wouldn't need much to make 
it a C replacement language.

i have a first crude hack of a ELF section header table working. 
it can currently describe itself :)

builds/hello:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .shstrtab ...

Here we go, hello.reds now results in a 1065 bytes binary (882 previously). 
For this bloat, you get the following information:

Section Headers:

  [Nr] Name              Type            Addr     Off    Size   ES 
  Flg Lk Inf Al

  [ 0]                   NULL            00000000 000000 000000 00 
       0   0  0

  [ 1] .text             PROGBITS        08048074 000074 000290 00 
   AX  0   0  4

  [ 2] .data             PROGBITS        08048304 000304 000085 00 
   WA  0   0  4

  [ 3] .shstrtab         STRTAB          00000000 000372 000017 00 
       0   0  1

Nice!

http://www.agner.org/optimize/promise convertor for obj files from 
PE, ELF to Mach-O and vice versa if it would help

Well, Red will probably not have to deal with object files directly, 
but anyway there are some good resources there. Too bad, the asm 
optimized subroutine library is not LGPL...

Ask, and I'm sure you will get a LGPL version.

You'd be surprised

Well, I'll try it when the need for such optimized code will come 
(not in the short-term). I'll probably need a subset only.

Why would you want an LGPL library for a BSD language?

For that matter, why would he make a GPL library for tutorial purposes? 
You can get in legal trouble for reading that code if you actually 
use what you learn to write code that isn't GPL licensed. This seems 
like poor planning, or just being mean. Is there at least a commercial 
license?

there is. and where do you get the idea from that this library is 
for tutorial purposes?

Brian: I don't intend to make Red deviate from the BSD road in anyway, 
I'm very much attached to keep it as open as possible. If some 3rd- 
party libraries with compatible license, can be used to add *optional* 
features, that shouldn't be a problem. The official Red distribution 
will always stay BSD.

Btw, I usually try not to read GPL code for features that I might 
have to implement in my pubic projects (not only Red). I've also 
stayed away from the host-kit source code for the same reason, knowing 
that I might have to work on similar features someday.

I didn't read the asm subroutine library source code, just the Manual, 
which is very informative.

Each routine has several implementations depending on the features 
available at runtime in the CPU (SSE, SSE2, SSE3,...). So, it's a 
bit too large for my needs (I would prefer selecting the best implementation 
at compile-time).

A few wildly different observations

I usually try to refrain from being a spelling nazi, but I did have 
a snicker at "pubic projects (not only Red)" :-)

The host kit is published but the licence is undetermined, so you 
could argue it's public domain

Hehe :-) Shouldn't chat on AltME while working.

At least not about those projects :-)

Unfortunately, the public domain argument won't get far:
**  Copyright 2010 REBOL Technologies
**  All rights reserved.

I just mean to say that Carl is creating a problem for himself by 
publishing with the monicker "open source" but undetermined licence

Absolutely.

or just take it as WTFPL

Even apart from the continuous creation of uncertainty, which everyone 
knows kills business

Anyway, it's hard to keep up with Red development. :-) I meant to 
say that in an unconnected context