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.

Red/System draft specifications released

I have published yesterday the first draft of Red/System's specifications. It is amazing how much time and energy writing such formal description can take. It is a working draft, so expect it to be updated often during next weeks. The document source is in MakeDoc format and stored on github, so feel free to fix typos and errors directly there.

As all features in the specifications are not yet implemented (I would say 85% is already done), I have added a todo-list on github's wiki to track the missing parts.

Also, all features are not yet set in stone, there are still a few important design decisions to take in the next weeks:

• Pointer! datatype: should we keep it or consider that struct! datatype can do the same job, so it's not worth the trouble of supporting an additional type for the syntactic sugar? Let's take an example with a pointer on integer and struct having a single integer member:
  

  p: &[integer! 0]
  p/value: 123
  
  p: struct [value [integer!]]
  p/value: 123
  

  Looks pretty much the same. Pointers have a shorter literal form, but once declared, structs could be used the same way and replace pointers in all use-cases.

• Array!: will it be necessary to add a standalone array! datatype or could its semantics be simply added to struct! or pointer! (if finally kept)?

• Booleans: there's currently no true/false support in Red/System, so that boolean values are not first class (can't be assigned nor passed as argument). This is quite limiting the expressibility of the language. Is using simple integer values (0,1 or 0,-1) enough or will it be better to support it as a separate datatype (logic!)?

The answers to these questions will come while working on unit tests and coding Red's runtime (written in Red/System). Feel free to share your thoughts about these features here, in comments, or on Google groups.

Comments relaxed

I wasn't aware that the comments on this blog required to have an account on Google/OpenID/... to be able to post comments. It was the default setting, but not my intention to make it hard or painful to post here, so I've relaxed this setting, anonymous posts are now allowed (you just need to pass a captcha).

Having fun with Red/System

A week after the first alpha release of Red/System compiler for Windows, we now have a working Linux/ELF support, thanks to Andreas help in deciphering the ELF format. Currently only syscalls are available, the dynamic library linking part is pending, it should be added before the end of March. The following Red/System "hello world" script:

Red/System [
   Purpose: "hello world script"
]

print "Hello World!"

compiles to a 162 bytes ELF binary, while a similar C code would produce a 5-6KB binary using Gcc...pretty good, no?

I must admit that supporting ELF wasn't in my short-term roadmap, but I changed my mind after seeing that a large part of people following Red project are Linux users. I think it was a good move as Linux users are also often hackers, so more inclined to contribute to an open source project like Red.

I was also impressed, yesterday, when I saw Kaj de Vos publishing a 0MQ mapping for Red/System (running only on Windows or Wine currently, as it needs dynamic linking). Even at this early stage, he managed to wrap 0MQ's main features. You can get his script from here (requires a libzmq.dll file that can be obtained from here, just put it in the same folder as the compiled binary). Here's the result after compiling and running the server and client versions:

The client sends 10 "Hello" messages to the server that replies to each of them with "World". Oh, did I mention that client.exe and server.exe files size is 3KB? :-)

I hope that people already playing with Red/System enjoy it as much as I did writing it.