Some of the many items in our TODO list for Vulcan.NET had to do with optimizing the runtime and adding some missing functionality (like passing USUALs by reference to CLIPPER methods) to it. We had already implemented some, like improving performance of the late binding system, but for obvious reasons we were not able to make any further improvements in Vulcan.NET. But now, with the fresh start of XSharp, it is a great opportunity to make things right and fast from the beginning. In this article we will discuss optimizations planned or already implemented on the USUAL, FLOAT and ARRAY data types, more about other types and parts of the runtime will follow in future articles.

The problem with the USUAL type

In Vulcan.NET, the VO-compatible USUAL type is defined as a structure (value type), which makes sense, as it is easier this way to emulate the semantics of the USUAL type, the same way as it behaves in VO. Structures are supposed to be lightweight, compact data types, usually a few bytes long, in order to achieve good performance when copying values from one to another, or passing them as parameters to methods etc. Examples of very common structures used in the system classes are System.Drawing.Point (8 bytes long) and Rectangle (16 bytes long).

The problem with the way the USUAL type is implemented in Vulcan.NET, is that it’s much longer than that. It is easy to check its size, with a simple line of code:

? SizeOf(USUAL)

Below is a list of some of the most visible new language features in the Core language of X# , compared to Visual Objects and Vulcan.

As you can see many new keywords were introduced, but these are positional: they will also be recognized as Identifiers on other places, so there is very little chance that you will have to make changes to avoid naming conflicts.

Entities and Statements

Below is a list of the new commands / entities inside X#. There are also some new options for existing commands. A full list of changes will be available later.

Some people have asked us how we are going to write our compiler, and if that is not very complicated.

The honest answer to that question is that it is indeed very complicated, but we use tools to help us doing it, which makes it a little bit easier.

In my previous blog article I have described how we are using the Roslyn infrastructure for a large part of our compiler, and that “all” we have to do is to create a recognizer for our language.

In this article I would like to elaborate a little bit about the language recognition part.

Antlr

For our language recognition we are using a tool called ANTLR (Another Tool for Language Recognition), written by Terence Parr, a professor from the University of San Fransisco.

This tool allows us to generate a major part of the language recognizer from language definition files. This language definition roughly consist of 2 elements:

  1. Tokens. These are the sequences of characters that form the Keywords, Identifiers, Constants (Strings, Integers, Floats, Symbols etc.) comments and whitespace in our language.
  2. Rules. These are the sequences of tokens that form our language.

From this definition the Antlr tool generates classes:

  1. A Lexer class that scans the source code and builds a list of tokens (the tokenstream)
  2. A Parser class that uses the rules and scans for the patterns from the language elements. This builds the Parse Tree.

Some people have asked us if we have lost our mind. And that is a very good question:

What they mean is that writing a compiler from scratch is a hell of a job and will take a lot of time.

But we are not writing a compiler from scratch

So we have NOT lost our mind. Let me explain that a little bit:

Early 2015 Microsoft has published the source code for its C# and VB compiler. This is called the Roslyn Project.

You can find this on the web on https://roslyn.codeplex.com/ and https://github.com/dotnet/roslyn.

Since this source code is licensed under the Apache 2.0 Open Source license we can use and change this code to create our X# compiler.

That means the the biggest part of the code in our compiler has been developed by the geniuses at Microsoft and has been tested by hundreds of thousands of developers all over the world. That is a HUGE benefit for our project.

So it is easy then?

No it is still not easy to write the compiler but a lot of work has already been done.

The following image displays a compiler in a schematic way:

 

compiler pipeline

Main menu

  • Buy
  • Contact
  • Free software