Red/System v0.2.1 released

This new release is bringing a lot of important bug fixes and some new features for Red/System. The new PRINT function might break some existing scripts, but should be easily fixable.

New features

• Variable-arguments function support
• RTTI function limited support
• Polymorphic and variadic PRINT function
• Command-line arguments access
• Added stack low-level manipulation native functions: push, pop
• Access to stack pointer and stack frame pointer (reading/writing)
• Subtracting two pointers is now possible
• Preprocessor improved to solve macros recursively
• New built-in hexdump debugging functions
• External library access unit tests (thanks to Peter)

PRINT function examples:


print 123
123

print "hello"
hello

print [123 "hello"]
123hello

print [123 tab "hello" lf "world" lf]
123 hello
world

a: 1 < 2
b: "hello"
print [a tab b/2]
true e


Bugfixes

• Complex arithmetic expressions involving pointers, path access and type casting are now much more reliable. 89 new unit tests were written to help fix the bugs and track regressions.

• Complete list of fixed issues available in Github's tracker.

Specification document

• Updated to match all new and changed features

Red runtime

• Memory allocator implemented in Red/System, documentation is pending.

As you can see, no vacation this summer for Red project!

Mac OS X port released!

Red/System Mac OS X port is now completed and on par with Windows and Linux ports. The new Mach-O file emitter supports all current Red/System's features including #syscall and #import directives.

Now that all major 3 OS are supported, I can say that the Mac OS X file ABI and function call ABI are really the most complicated one to support from scratch, the Windows one (PE/COFF) being the simplest (with its own set of oddities, but simpler) and Linux's ELF somewhere in between. Among the issues we had to identify and deal with:

• Stack alignment on 16 bytes constraint at the point of every library call (meet with the infamous "gate keeper" code causing segfaults and bus errors on misaligned calls)

• Extra stack entry for each BSD system call.

• Working around dynamically linked libraries info extraction that need to be copied from each library header to the generated executable image. This could have prevented cross-compilation.

• The need for direct CALL opcode in the generated IA-32 code instead of indirect ones used for PE and ELF library function callings.

After a lot of efforts spent mostly in debugging, here is the result:

As you can see, it is fully functional and all unit tests are passing!

A couple of notes about usage:

• The library you declare in #import definition needs to be located in /usr/lib/ or else, you need to provide a full path to the library.

• The file emitter should support up to 255 imported libraries (Mach-O limit), but it has been tested only with one so far (libc.dylib), so if you have anything odd happening with more than one imported library, please fill a bug report in github's tracker, or post a message to the mailing-list.

Enjoy!

Red/System goes beta!

This is a major milestone reached on the Red roadmap. Red/System is now in a beta state, which means that it is good enough, both in design and implementation to be used for building applications.

A huge collective effort has been made by all contributors to reach that state during June, in a single month, we produced:

• 190 new commits (total = 354 now), more in a month than in the three previous ones!
• 3600 more unit tests (total = 6230 now)
• 2800 more LOC (total ~ 6000 LOC now)
• 70 issues closed on github's tracker
• 8 more revisions of specification document

This is what can be called an "intense" month of work!

There are still a lot of features that are lurking in the corner for inclusion. Red/System features are not set in stone, the language will evolve to match our needs, as a support tool for building Red. It will now follow a bit more organized release cycle to help users and contributors have a more stable base to work with.

The version number has been bumped to v0.2.0. From now on, only non-disruptive changes will be pushed on the main branch, other changes will go into a separate development branch until we decide to make a new release, merge new features and increment the version number. This cycle should be short, on a weekly basis (each week or two, depending on the development branch content). If this organization does not fit well the development progress, we will adapt to a more adequate one.

I cannot resist to show you the new unit testing output when running the complete tests suite (just run the %tests/run-all.r script):

Quick-Test v0.5.0
REBOL 2.7.6.3.1
Red/System Test Suite

ok - logic.............................76 / 76
ok - integer............................0 / 0
ok - byte..............................40 / 40
ok - c-string..........................20 / 20
ok - struct...........................116 / 116
ok - pointer...........................68 / 68
ok - cast..............................66 / 66
ok - alias.............................22 / 22
ok - length............................11 / 11
ok - null..............................11 / 11
ok - not...............................24 / 24
ok - size..............................36 / 36
ok - function...........................2 / 2
ok - exit...............................9 / 9
ok - return............................24 / 24
ok - modulo............................20 / 20
ok - infix..............................2 / 2
ok - conditional.......................13 / 13
ok - byte-auto.......................3492 / 3492
ok - integer-auto....................2106 / 2106
ok - alias-compile......................3 / 3
ok - cast-compile......................16 / 16
ok - comp-err...........................4 / 4
ok - exit-err...........................3 / 3
ok - int-literals-err...................1 / 1
ok - output.............................3 / 3
ok - return-err.........................5 / 5
ok - conditions-required-err...........23 / 23
ok - inference-err......................1 / 1
ok - callback-err.......................3 / 3
ok - infix-err..........................2 / 2
ok - not................................1 / 1

ok - Red/System Test Suite...........6230 / 6230
  in 0:00:16.3

A big thank to all the following contributors who are working hard each day to help me bring Red to life:

Andreas Bolka

Rudolf W.Meijer

Kaj de Vos

Peter W A Wood

Cheers!

EDIT: for those coming here for the first time and willing to test Red/System, please follow the link to Github's repository, you will find some instructions there for getting started.

Short look on last three months

Three months have passed since Red has gone public. It seems short, but a lot happened since then and I wanted to sum up the work accomplished for the people interested in Red that don't have the time to follow the progress daily on every channel.

Development

• Red/System is implemented at 98%
• ~2600 unit tests were created (thanks to Peter WA Wood)
• Red/System language specification draft added, now close to 95% of completion
• Code base almost doubled: 60KB to 110KB (~3200 LOC)
• 164 commits on Github, 44 by contributors
• 4600+ page views on Github's Red repository

Main new features

• New datatypes: byte!, logic!, pointer!
• Linux port (thanks to Andreas Bolka)
• Syllable port (thanks to Andreas and Kaj)
• MacOS X port in progress

Community

• 0MQ library support (Kaj de Vos)
• Quick-Test framework (Peter WA Wood)
• 3 contributors on Github, 22 followers
• 65 issues opened on Github, 53 closed (thanks to Rudolf Meijer)
• 8 blog posts, 10'000+ page views
• #red_lang: 130 tweets, 39 followers
• Mailing-list: 32 members, 45 topics, 150 posts
• IRC: 5 people permanently logged

Last but not least, we got an article on OSNews two days ago that boosted the page views on red-lang.org (+3'000) and Github's repo (+1'000).

Thanks for all people supporting Red, one way or another. This is a very good start and a big incentive for me to work even harder on the next steps.

Red meeting on 28/05 at Lille

I will present Red language and the Cheyenne Web Server at Lille (France) on May, 28 to a group of REBOL and Red users. The presentations will be done in french, but if some none-french speakers want to come, I will try to do it both in french and english.

Detailed information to get there are available in this thread from RebelBB forum. See you there on Saturday!

Red/System compiler overview

Source Navigation

As requested by several users, I am giving a little more insights on the Red/System compiler inner workings and a map for navigating in the source code.

Current Red/System source tree:

 red-system/
     %compiler.r        ; Main compiler code, loads everything else
     %emitter.r         ; Target code emitter abstract layer
     %linker.r          ; Format files loader
     %rsc.r             ; Compiler's front-end for standalone usage

 formats/               ; Contains all supported executable formats
     %PE.r              ; Windows PE/COFF file format emitter
     %ELF.r             ; UNIX ELF file format emitter

 library/               ; Third-party libraries

 runtime/               ; Contains all runtime definitions
     %common.reds       ; Cross-platform definitions
     %win32.r           ; Windows-specific bindings
     %linux.r           ; Linux-specific bindings

 targets/               ; Contains target execution unit code emitters
     %target-class.r    ; Base utility class for emitters
     %IA32.r            ; Intel IA32 code emitter

 tests/                 ; Unit tests

Once the compiler code is loaded in memory, the objects hierarchy looks like:

 system/words/          ; global REBOL context

 system-dialect/        ; main object
     loader/            ; preprocessor object
         process        ; preprocessor entry point function
     compiler/          ; compiler object
         compile        ; compiler entry point function

 emitter/               ; code emitter object
      compiler/         ; short-cut reference to compiler object
      target/           ; reference the target code emitter object
          compiler/     ; short-cut reference to compiler object

 linker/                ; executable file emitter
     PE/                ; Windows PE/COFF format emitter object
     ELF/               ; UNIX ELF format emitter object

Note: the linker file formats are currently statically loaded, this will be probably changed to a dynamic loading model.

Compilation Phases

The compilation is a process that goes through several phases to transform a textual source code to an executable file. Here is an overview of the process:

1) Source loading

This is a preparatory phase that would convert the text source code to its memory representation (close to an AST). This is achieved in 3 steps:

1. source is preprocessed in its text form to make the syntax REBOL-compatible
2. source is converted to a tree of nested blocks using the REBOL's LOAD function
3. source is postprocessed to interpret some compiler directives (like #include and #define)

2) Compilation

The compiler walks through the source tree using a recursive descent parser. It attempts to match keywords and values with its internal rules and emits:

• the corresponding machine code in the code buffer
• the global variables and complex data (c-string! and struct! literals) in the data buffer

The internal entry point function for the compilation is compiler/comp-dialect. All the compiler/comp-* functions are used to recursively analyze the source code and each one matches a specific semantic rule (or set of rules) from the Red/System language specification.

The production of native code is direct, there is no intermediary representation, machine code is generated as soon as a language statement or expression is matched. This is the simplest way to do it, but code cannot be efficiently optimised without a proper Intermediate Representation (IR). When Red/System will be rewritten in Red, a simple IR will be introduced to enable the full range of possible code optimisations.

As you know, a Red/System program entry point is at the beginning of the source code. During the compilation, the source code in the global context is compiled first and all functions are collected and compiled after all global code. So the generated code is always organised the same way:

• global code (including proper program finalization)
• function 1
• function 2
• ...

The results of the compilation process are:

• a global symbol table
• a machine code buffer
• a global data buffer
• a list of functions from external libraries (usually these are OS API mappings)

The compiler is able to process one or several source files this way before entering the linking phase.

3) Linking

The linking process goal is to create an executable file that could be loaded by the target platform. So the executable file needs to conform to the target ABI for that, like PE for Windows or ELF for Linux.

During the linking, the global symbol table is used to "patch" the code and data buffer (see linker/resolve-symbol-refs), inserting the final memory address for the pointed resources (variable, function, global data). The different parts to assemble are grouped into so-called "sections", that can be themselves be grouped into "segments" (as, e.g., in ELF).

Finally, some headers describing the file and its sections/segments are inserted to complete the file. The file is then written down on disk, marking the end of the whole process.

Static linking of external libraries (*.lib, *.a,...) will be added at some point in the future (when the need for such feature will appear).

I hope this short description gives you a better picture on how Red/System compiler works, even if it is probably obvious for the most experienced readers. Feel free to ask for more in the comments, or better, on the Google Groups mailing-list.

Update on Red/System progress

Here is a quick update on Red/System progress.

Specifications Draft

Draft has gone through several revisions. Several decisions mainly regarding pointers handling have been taken with simplification and disambiguation as main goals:

• Struct! values are now passed by reference (a syntax for passing by value will be added in future), simple arithmetic (+, -) can be used on struct references.

• String! was renamed to c-string! to avoid possible future collision with a Unicode-aware string! type. However, this case is not totally solved, there are still some possible issues, like the literal syntax. As c-string! values are passed by reference, simple arithmetic was added too.

• Pointer! datatype was restricted to point to integer! values only. It is more consistent with new c-string! and struct! which are both (implicit) pointers already, and that removes the need for verbose pointer syntax.

• Array! datatype: no decision taken for now, we will see if (both explicit and implicit) pointer arithmetic support will be sufficient during Red's runtime implementation.

• Logic! datatype was added as a first class type. This makes boolean literal values (true, false) and conditional expressions assignable to variables and can be passed as argument or returned by user functions. Logical NOT operator was also added as well.

• Byte! datatype (unsigned byte value) was added to ease string byte accesses.

• Limited type inference was added for function's local variable and return value types.

A couple of things to keep in mind about Red/System design:

• during the implementation of these specifications, some better design options might appear in light of the implementation decisions.

• at some point, when the bootstrapping phase will be over, Red/System will be rewritten entirely in Red, giving an opportunity to fix and improve the design (also helped by several months of feedback from Red/System usage).

Implementation Progress

Several items from the todo-list have been implemented in the last week, the most notable ones being:

• Logic! datatype support
• NOT function addition
• EXIT and RETURN support (for early exit from functions)

Among other changes:

• ELF emitter has been extended a bit to support sections table (thanks to Andreas).

• An experimental Mach-O (OS X) support is under work by Rebolek.

• Several unit test files have been added to the repository recently, using a temporary minimalistic approach, that will be soon superseded by a real dedicated framework.

• We are close to have a nice, small and lean unit test framework (Quick Test), created by Peter W A Wood for Red/System, covering all our needs (internal and external testing).

An interesting side note on how implementation can influence back the design:

During the implementation of Quick Test framework, Peter, while writing an integer to string conversion function, came up with a code pattern that is common in REBOL, but wasn't planned for Red/System: declaring private functions inside a function to hide them from global context. The pattern looked like this:

    prin-int: func [...][
        ...
        prin-digit: func [...][...]
        ...
        prin-digit ...
        ...
    ]

I was surprised when I tested the code he sent me, as I never did anything in the implementation to support such case explicitly. It was working because of a side-effect caused by the way functions are compiled in Red/System: the functions bodies are all gathered and compiled at the end of the global context code, regardless of where they are defined. The side-effect making the inner "prin-digit" function private is caused by a global function variable being declared inside a local scope, but without being part of the function specification block. So, once the outer function compiled, the "prin-digit" symbol is lost, making the function unreachable from global context and forever hidden.

I was thinking about adding a way for users to create private contexts much later in the future (relying on Red/System source header), but we have the opportunity to have an equivalent feature, right now and without adding anything to the code! So, I am giving it some time to see if the side-effect can be safely made permanent to keep that feature, and in the meantime, added it to the Possible Evolutions part of the specifications.

In the next days, I will work on:

• finishing implementing the features from the todo-list
• merging the unit tests framework once ready
• adding new unit tests

In my next blog article, I will give an overview of Red/System compiler internals as requested by some followers.