Summary

LCCC and XLang

Copyright

LCCC - Intro to XLang Design and Examples

Intro to XLang

XLang is the intermediate architectuer and intermediate representation language used by the LCCC project for lowering and optimizing programs from a source language to machine code.

It is a stack based language that was originally designed in early 2020 by myself as part of the LCCC project, though it has undergone some revisions since.

XLang is a strict stack-base architecture - within a function, all instructions, also referred to as expressions, will pop a certain number of input values from a stack, perform some operation, and push each output value back to the same stack. There is no random access to the stack (though the pivot instruction offers the ability to move values up by popping off two groups then pushing them in the opposite order), and the stack cannot be addressed. You also cannot modify an entry on the stack, but would rather have to pop the value and then push the new value.

Local variables are offered when mutable, addressible memory is required.

There are two kinds of values on the stack: rvalues and lvalues. An rvalue is a simple value, such as 0, 512, 2.71828, a pointer, or a composite value like a struct. An lvalue is a synthetic value that designates some part of memory, known as an object.

Computations are performed on rvalues, while lvalues must be read or written to.

The xlang crate graph

Interacting with xlang programmatically will typically require using the xlang crate graph.

These crates can be obtained by using a git dependency on the lccc repository (https://github.com/lccc-project/lccc) or cloning it as a submodule.

You can also interact with these using the ABI structure the crates expose, but this is not presently supported.

The main crate graph starts with the xlang crate, which depends on the rest of the main crate graph, and reexpotrs them. It also links the xlang_interface system library, which provides a minimal api surface for ensuring different plugins perform tasks like allocation and deallocation consistently. The remaining crates are:

xlang_host, which exposes primitive abstractions over the host environment (exported as xlang::host)
xlang_abi, which exposes ABI-safe data structures and primitives, many which match or closely follow the interface of standard library data structures (exported as xlang::abi)
xlang_target, which exposes structures that describe the properties of targets which code may be generated for by lccc and a mechanism to query target properties (exported as xlang::target)
xlang_struct, which exposes a structural representation of xlang ir

The xlang crate then is dependend upon by a few optional crates for writing plugins:

xlang_backend exposes interfaces that abstract on backend plugins
xlang_frontend exposes interfaces that abstract on language frontends
xlang_opt exposes interfaces that abstract on optimizers

These optional crates are not required, but may improve the experience of writing these kinds of plugins.

XLang Plugins

Plugins are used by drivers to perform tasks relevant to the translation from source code to machine code. They are system dylibs (IE. a shared object or dll) with a special entry point that is called by the driver.

There are 3 main kinds of plugins:

Frontends, which read source files and produces xlang ir,
Transformers, which accept and modify xlang ir in place (most transformer plugins will be optimization passes), and
Backends, which consumes xlang ir and produce something else, such as machine code, or a lower-level IR (like wasm).

Each main plugin has a different entry point, exported as an unmangled symbol using the lcrust-v0 calling convention (via the rustcall!() macro from xlang_host), that exposes a trait object that satisfies the appropriate trait in the xlang::plugin module. Trait objects are captured accross the abi boundary using types in xlang_abi::traits.

Frontend plugins expose xlang_frontend_main, which returns a trait object satisfying XLangFrontend. Backend plugins expose xlang_backend_main, which returns a trait object satisfying XLangBackend. Transformer plugins expose xlang_plugin_main, which returns a trait object satisfying XLangPlugin.

As plugins share data structures accross an ABI boundary, ABI-safe types provided by xlang_abi are used throughout much of xlang, and the lccc infrastructure.

Building IR

IR Building occurs using the xlang_struct crate, which is also reexported via the xlang::ir module.

The IR is represented as a number of structs, which can be constructed and modified by plugins. The structs contain abi-safe data structures provided primarily by the xlang_abi crate.

Each plugin is passed a mutable reference to the top level File by the accept_ir method of the XLangPlugin trait. Frontends would then build the IR and write it to the reference, backends would read the IR and build it's output, and transformers modify the File in place.

Stack Operations in XIR, or how to do interesting things

Many operations in XIR are typed, and perform some transformation on the values taken from the stack before pushing new ones. However, three expressions manipulate the stack in more generalized ways. The expressions are pivot, pop, and dup, and are collectively called the stack operations.

pop and dup are both relatively straightforward for anyone who's worked with a stack, but has a few interesting features. Both are provided with a single integer value we'll call n. Both instructions, pop n and dup n, pop n values from the stack. With pop n these values are discarded, and dup n pushs the values in the reverse order they were popped, then repeats the process. As a net result, dup n duplicates a group of n values from the stack. In the XIR parser, these expressions may be written simply as pop or dup, in which case an n of 1 is inferred.

pivot is an interesting expression. It is provided with 2 values, which we'll call m and n. Strictly speaking, pivot m n pops n values from the stack in a group we'll call S, and then pops m values from the stack in a group we'll call T. It then pushes the values in S in the opposite order that they were popped (or, the same order they appeared on the stack in the first case), and then pushes the values in T. This is a powerful operation in XIR, as it can provide effectively random access to the value stack in a proper stack operation.

There notable cases are particularily useful for lowering source languages, though others may be useful in niche cases, and show up in optimized IR that makes heavier use of the stack compared to local variables (which are stored primarily in memory).

pivot 1 n, moves 1 value to the top of the stack from n values down.
pivot n 1 moves 1 value from the top of the stack to n values down (not including that value itself),
pivot n n swaps two equally sized groups of n values.

Like pop and dup, pivot may appear in two special-cased forms. A single input like pivot n means pivot n n (performs the swap operation), and no inputs like simply pivot means pivot 1 1 (swaps 1 value).

An Example, the Tiny language lowered to XLang

The Tiny Language is a simple language that was introduced in a compilers course at my university. While the course only referred to the lexical and syntatic grammar of the language, I have personally expanded it to include semantic analysis and codegen (to JVM bytecode), and even added a few extensions.

The grammar of the language is, in ABNF:


QUOTE := %x22

STRING_CHAR := %x01-09 \ %x0B-0C \ %x0E-21 \  %x23-7F \ %x80-D7FF \ %xE000-10FFFF

string-literal := <QUOTE> [*<STRING_CHAR>] <QUOTE>

DIGIT := %x30-39

number-literal := *<digit>["." *<digit>]

literal := <number-literal> / <string-literal>

identifier := <XID_Start>[*<XID_Part>]

file := *<method-decl>

method-decl := <type> ["MAIN"] <identifier> "(" <param-list> ")" <block>

type := "INT" / "STRING" / "REAL"

param-list := [<param> / (<param> "," <param-list>)]

param := <type> <identifier>

block := "BEGIN" [*<statement>] "END"

statement := <declaration> / <assignment> / <read> / <write> / <if> / <block> / <return>

declaration := <type> <identifier> [":=" <expression>] ";"
assignment := <identifier> ":=" <expression> ";"
read := "READ" "(" <identifier> "," <string-literal> ")" ";"
write := "WRITE" "(" <expression> "," <string-literal> ")" ";"
if := "IF" "(" <bool-expression> ")" <statement> ["ELSE" <statement>]
return := "RETURN" <expression> ";"

bool-expression := (<expression> ("==" / "!=") <expression>)

The semantics of Tiny are fairly simple: READ reads from a named file, and WRITE writes to it. IF takes one branch if a value evaluates to true, and another if it evaluates to false. The function marked MAIN is run at startup.

Using this, we can write a few test programs, taken from a full compiler, and explore how they could be translated to XLang IR.

For the compilation of these tests, I have elected to use a basic variation of the Itanium Name Mangling scheme. INT, being a 32-bit integer is encoded as i, REAL as d, and STRING as u6string

test1 - A fairly basic example

INT f0(REAL x)
BEGIN
    RETURN x;
END

In a basic xlang lowering, we can translate the above to:

public functon _ZN5test12f0Ed(float(64)) -> int(32){
       // [float(64)]
       convert weak int(32) // [int(32)]
       exit 1
}

A very simple program with a very simple translation - convert the input value to a 32-bit integer, then return it.

Function parameters are placed on the stack in their appropriate order and are already there when the function begins execution. convert weak int(32) then pops a value off the stack, in this case float(64), performs a conversion, and pushes the result, in this case int(32).

exit 1 then pops 1 value off the stack and "exits" (that is, returns from) the current function with that popped value, which is the return value.

To show the behaviour of the program, in loose terms, to validate that the lowering is correct, stack type annotations were added to show the state of the stack after each statement. These aren't interpreted by the XIR frontend (as they appear in comments), but are provided as a visual guide to show the world as understood by xlang.

test2 - A simple executable program

INT MAIN main() BEGIN
   INT x;
   READ(x,"test-stdin");
   WRITE(x,"test-stdout");
END

This needs some more work, and we need some dependencies for the READ and WRITE statements, as well as for creating strings (an extension allows us to ). We're also going to lower the MAIN function in two steps: one step compiling the function directly, and a second generating a call stub that does some initialization, calls the main function, and then returns. The definitions of the __tiny_read_INT, __tiny_write_INT, __tiny_const_string, __tiny_rt_init, and __tiny_rt_cleanup are left as an implementation-detail and are largely irrelevant for this program:

public function __tiny_read_INT(*void()) -> int(32);
public function __tiny_write_INT(int(32), *void());

public function __tiny_const_string(*const readonly nonnull char(8)) -> *void();
public function __tiny_rt_init();
public function __tiny_rt_cleanup();

public function _ZN5test24mainEv() -> int(32){
    // []
    const global_address function(*void())->int(32) __tiny_read_INT // [*function(*void())->int(32)]
    const global_address function(*const readonly nonnull char(8)) -> *void() __tiny_const_string // [*function(*void())->int(32), *function(*const readonly nonnull char(8))->void()]
    const *char(8) "test-stdin\n" // [*function(*void())->int(32), *function(*const readonly nonnull char(8))->void(), *char(8)]
    derive *const readonly nonnull char(8) // [*function(*void())->int(32), *unction(*const readonly nonnull char(8))->void(), *const readonly nonnull char(8)]
    call function(*const readonly nonnull char(8))->*void() // [*function(*void())->int(32), *void()]
    call function(*void())->int(32) // [int(32)]
    const global_address function(int(32),*void()) __tiny_write_INT // [int(32), *function(int(32),*void())]
    pivot 1 1 // [*function(int(32),*void()), int(32)]
    const global_address function(*const readonly nonnull char(8)) -> *void() __tiny_const_string // [*function(int(32),*void()), int(32), *function(*const readonly nonnull char(8)) -> *void()]
    const *char(8) "test-stdin\n" // [*function(int(32),*void()), int(32), *function(*const readonly nonnull char(8)) -> *void(), *char(8)]
    derive *const readonly nonnull char(8) // [*function(int(32),*void()), int(32), *function(*const readonly nonnull char(8)) -> *void(), *const readonly nonnull char(8)]
    call function(*const readonly nonnull char(8))->*void() // [*function(int(32),*void()), int(32), *void()]
    call function(int(32),*void()) // []
    const int(32) 0 // [int(32)]
    exit 1
}

public function main() -> int(32){
    const global_address function() __tiny_rt_init // [*function()]
    call function() // []
    const global_address function()->int(32) _ZN5test24mainEv // [*function() -> int(32)]
    call function()->int(32) // [int(32)]
    const global_address function() __tiny_rt_cleanup // [int(32), *function()]
    call function() // [int(32)]
    exit 1
}

External functions can be declared by giving the signature without a body, ending the line with ;.

We use the const global_address expresion to push the address of a global, in this case a function. const in general pushes a sole constant value to the stack (such as an scalar value, uninitialized value, or, as in this case, the address of some function to cal). const *char(8) <string-literal> is another example of this, which pushes a string literal with the given type (in this case, a pointer, so the string goes into rodata somewhere else in memory rather than appear directly on the stack).

The derive expression following the string literal push is an type manipulation instruction for pointers. It changes attributes on a pointer type used by the optimizer. In many cases it also forms a new edge in the provenance¹. The Pointer model of xlang is not discussed in this post.

The call expression, intuitively, calls a function. It pops off the parameter list specified by the signature it is given, then pops the function to call (usually a function pointer). It then performs a call by pushing the arguments in the callee frame, and beginning execution with the first statement in the function. After that function returns (via exit), if the function doesn't return void(), the call expression pushes the return value from the function back in the callers frame.

We've examined the pivot expression in detail in a previous section, so it won't be explained again here.

test3 - Adding some Control (Flow)

Our third, and final example, is another program that this time includes the use of control flow, through IF.

INT MAIN main() BEGIN
   INT x;
   INT y;
   READ(x,"test-stdin");
   IF (x==1)
       y := 0;
   ELSE
       y := x;
   WRITE(y,"test-stdout");
END

Here, we read a value from test-stdin into x, then compare x and 1. If they are equal, then set y to 0 otherwise set y to x. We then write the value of y to test-stdout.

For this example, the entry point main is omitted, and is exactly the same as the one from test2. We'll only show the actual written code translated

public function __tiny_read_INT(*void()) -> int(32);
public function __tiny_write_INT(int(32), *void());

public function __tiny_const_string(*const readonly nonnull char(8)) -> *void();

public function _ZN5test34mainEv() -> int(32){
    // []
    const global_address function(*void())->int(32) __tiny_read_INT // [*function(*void())->int(32)]
    const global_address function(*const readonly nonnull char(8)) -> *void() __tiny_const_string // [*function(*void())->int(32), *function(*const readonly nonnull char(8))->void()]
    const *char(8) "test-stdin\n" // [*function(*void())->int(32), *function(*const readonly nonnull char(8))->void(), *char(8)]
    derive *const readonly nonnull char(8) // [*function(*void())->int(32), *unction(*const readonly nonnull char(8))->void(), *const readonly nonnull char(8)]
    call function(*const readonly nonnull char(8))->*void() // [*function(*void())->int(32), *void()]
    call function(*void())->int(32) // [int(32)]
    dup // [int(32),int(32)]
    const int(32) 1 // [int(32),int(32),int(32)]
    cmp_eq // [int(32),uint(1)]
    branch not_equal @0 // [int(32)]
    pop // []
    const int(32) 0 // [int(32)]
    target @0 [int(32)] // [int(32)]
    const global_address function(int(32),*void()) __tiny_write_INT // [int(32), *function(int(32),*void())]
    pivot 1 1 // [*function(int(32),*void()), int(32)]
    const global_address function(*const readonly nonnull char(8)) -> *void() __tiny_const_string // [*function(int(32),*void()), int(32), *function(*const readonly nonnull char(8)) -> *void()]
    const *char(8) "test-stdin\n" // [*function(int(32),*void()), int(32), *function(*const readonly nonnull char(8)) -> *void(), *char(8)]
    derive *const readonly nonnull char(8) // [*function(int(32),*void()), int(32), *function(*const readonly nonnull char(8)) -> *void(), *const readonly nonnull char(8)]
    call function(*const readonly nonnull char(8))->*void() // [*function(int(32),*void()), int(32), *void()]
    call function(int(32),*void()) // []
    const int(32) 0 // [int(32)]
    exit 1
}

branch and target are the two main new statements here, along with cmp_eq.

cmp_eq is the simplest. It compares two values and pushes 0 if they are unequal, and 1 if they are equal. The pushed value is of type uint(1) (a 1 bit unsigned integer type), though this rarely matters.

branch "branches" to a target (which can be considered like a label in assembly or C), when some condition is satisfied. You can specify either a condition code, such as not_equal used here, always, or never, to indicate when to branch. When a condition is specified, it will pop a value from the stack which has an integer type. The relation of that value to 0 is then checked according to the condition code. In the case of not_equal, the branch is taken when the value used is not equal to 0. branch always and branch never do not pop a value, and will either always (or never) take the branch. In all cases, branch may perserve a certain set of values from the top of the stack into the target when it takes the branch.

The target statement can be used to declare a target of a branch. As part of the statement, an "incoming" stack is specified, which is preserved from branches to the target that are taken. It is also preserved when "falling through" into a target from a previous expression, in this case, the values are also taken from the top of the stack and the bottom values are discarded. Certain expressions, such as exit or branch always are treated as "diverging" (IE. they do not resume execution, so they do not have an output stack). These will typically be followed by a target so execution can be reached from another part of the program.

The remainder of the function is similar to the second example, so it is not explained here.

Comments

Comments about this post may be left on the issue tracker.

Copyright

https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html

Rust Compilers and the Rust Spec

Disclaimer

The author of this post is a Lead and Developer of the LCCC project. This post is does not represent the views of the LCCC Project and is purely the opinion of the author.

The author of this post does work on the Rust Specification along side the Specification Team. This post is not intended to represent any consensus of that team, nor any demand to that team, merely as an opinion to consider.

Background of the Rust Spec

Work on the Rust Specification was started by a mandate put forth in RFC 3355, as a result of that RFC, a Formal Team was created, which started work on the Rust Specification in November of 2023.

While a complete developmental history of the Spec is not in scope for this, as of the date of writing (March 14th, 2024), the process has roughly been:

(Pre 2023-11) Background work, initial setup, Foundation Hires an Editor
(2023-11) T-spec setup work, meeting arrangements, first official meeting
(2023-12 - 2024-01) Tooling discussions, first sample chapters written and presented to Team/Stakeholders
(2024-01 - 2024-02) Review of sample chapters, refinement of tooling discussions, discussions (including with teams) on Specification Structure
(2024-03) First direct work started on Rust Specification Chapters

The Rust Specification does not define the language, but merely describes the language. From the specification RFC

The goal is not to change how the language evolves; the relevant teams (Language, Libs-API, …) remain in charge of the evolution of their respective parts of Rust, and will continue to use processes as they see fit (e.g. RFCs).

However, it is anticipated that the evolution process will eventually include work on the spec, ensuring that once the spec is in a "complete" state, it will remain in that state in sync with the rest of the language.

Background of Rust Compilers/Implementations

To my knowledge, including the Reference compiler rustc, there are 4 purported implementations of the Rust Programming Language, in various stages of development. The implementations that are not the reference compiler, known typically as "Alternative Implementations" or "Alternative Compilers" (the two are used in this post interchangibly, though Implementation conceptually includes the standard library, which may or may not be implemented separately), are developed for a variety of reasons. Some of the reasons for alternative implementation development include solving issues with rustc, such as bootstrapping or lack of target support, better integration with toolchains, tooling, and ecosystems other than llvm, or simply because the maintainers believe they can (I personally like to refer to this last reason as the "Mountain Climber Reason").

The first Rust compiler, being the Reference compiler, known commonly as the program rustc (and this blog will continue to refer to it as rustc) was released in the stable 1.0 version in May 2015, though work on it (and the Rust language) started as early as 2009. As the reference implementation, the evolution of rustc corresponds exactly to the evolution of the Rust Programming language, with a new stable version of each every 6 weeks - the most recent one as of the date of writing being Rust 1.77 (released on March 21st, 2024) with the next stable version being Rust 1.78 (stable on May 2nd, 2024)¹.

The first alternative compiler of rust, mrustc started development even before the first stable version of rust (With a first commit to the mrustc repository on Novmeber 28th, 2014). mrustc, developed primarily by thepowersgang on github, is primarily intended to ease the bootstrapping process of rustc, by providing a compilation path to various versions of rustc through a non-rust language (in the case of mrustc, C++14). The exact development history of mrustc could not be discovered by the author in the 15 minutes of research done on it, but currently it supports Rust 1.19, Rust 1.29, Rust 1.39, and Rust 1.54, with Rust 1.74 support being actively worked on. The support for Rust 1.54, the most recent fully supported version, was added in December of 2021.

The second alternative compiler of rust, gcc-rs also started sometime in 2014, shortly after the start of mrustc, though work on the most recent iteration of the frontend started arround 2020 after funding was provided for the work. The current status is a work in progress implementation targetting rust 1.49. As of March 3rd, 2024², gcc-rs has made substantial progress towards this support, recently adding a significant portion of the support for the format_args!() macro, and have implemented a basic println!() macro using that support. The println!() macro also leveraged already completed work, such as the work done for iterators.

The third alternative compiler is part of the lccc project (which I work on). Inclusion of rust in the project began in 2020 under the group Lightning Creations when the project that then contained lccc, lcnix, considered using rust code as part of its development. While development of the top-level lcnix project was discontinued, many of its subprojects continued development (and many were absorbed into lccc). The entire project has seen a few iterations (two main ones in C++, one now in Rust with an MSRV of 1.54), and the Rust frontend itself several iterations. The most recent iteration of the Rust frontend began in 2023, with a bottom up test-iterative approach. The most recent thing completed in the frontend is various complex branches (if/else statements and some basic matches).

Rust Specification and Rust Implementations

The Specification RFC states the following in relation to alternative implementations

It is not a primary goal of the specification to aid in the development of alternative Rust implementations, although authors of alternative compilers might still find the specification to be useful.

Based on discussions with project members³, this in particular refers to the fact the specification will not, as part of it's initial goal, be intended to validate implementations. However, in more recent discussions, it seems me that such implementations are not being considered as a consumer of the specification either.

It is reasonable that the initial scope of the specification would not render it complete enough to fully validate an implementation and be used for that purpose, however I think it is reasonable to conclude that it should eventually include that scope and thus implementors as consumers is something the spec now should consider.

The Future of Rust

Currently, Rust has 4 different compilers, in various phases of development. In addition to rustc, developed in tandom with the prescriptive work of the Rust project by the lang team, libs-api team, types team, and operational semantics team, the current set of implementations are intent on ensuring compatibility in various manners (including collaboration with the project). However, such work currently requires substantial amounts of research work, that should eventually be ameliorated by the Rust Specification.

It is not reasonable to expect that all implementations of Rust in the future will start or continue to collaborate to the extent that the existing ones do now, and they might expect a specification to inform them of the necessary elements for conformance. The specification should thus eventually be that specification implementations want. In order to ensure that it will be, the work on the specification now should prepare it for that future. It does not necessarily need to be perfect now, but it should be able to be made as good as it needs to be in the future.

Conclusion

Both lccc and gcc-rs have, as part of their stated goals, the promotion of the development of a Rust Specification. In my view, that goal is completed when any implementation can be written solely from the technical document signed off by the Rust Project as the official Rust Specification.

The 4 existing compilers for Rust will not be the last ones, particularily if gcc-rs and/or lccc succeeds in producing a production compiler. In my opinion, there will be another production-targetting Rust implementation either complete or in-progress within 5 years of this post, and in 10 years there will be a more substantial sphere of competition. The Rust project, including the specification, should be ready for it. The Specification today should consider implementors as a class of consumer of the spec, and should accept implementors as stakeholders in the spec, albeit future stakeholders. It would not be good if we write a spec today that rejects implementors, to a design that cannot be adapted to one useful for ensuring compliance and thus compatibility, in a future where use of a compiler other than rustc is as commonplace as use of rustc itself.

https://releases.rs/docs/1.77.0/

https://rust-gcc.github.io/2024/03/05/2024-02-monthly-report.html

https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1347822649

Copyright

Copyright Information

All chapters of all novels contained herein are licensed under the CC-BY-SA 4.0 License, or, at your option, any later version. A copy of the license is provided, or the official legal text is available at https://creativecommons.org/licenses/by-sa/4.0/legalcode.en.

Rendering

The rendering of this site and all of the novels contained herein is done by the program mdbook, and includes stylesheets and other creative choices in the design of the rendering whether manually written or programmatically generated as applicable, and such is authored by its contirbutors and is used under the terms of the Mozila Public License 2.0, of which a copy can be found at https://github.com/rust-lang/mdBook/blob/master/LICENSE.

The rendering of this site uses the font OpenSans, which is used under the terms of the Apache v2.0 license. A copy of this license, as applied to the font, is found here. Additionally, the rendering of this site uses the font Source Code Pro, which is used under the terms of the SIL Open Fonts License. A copy of this license, as applied to the font, is found here

Creative Commons Attribution-ShareAlike 4.0 International

Creative Commons Corporation (“Creative Commons”) is not a law firm and does not provide legal services or legal advice. Distribution of Creative Commons public licenses does not create a lawyer-client or other relationship. Creative Commons makes its licenses and related information available on an “as-is” basis. Creative Commons gives no warranties regarding its licenses, any material licensed under their terms and conditions, or any related information. Creative Commons disclaims all liability for damages resulting from their use to the fullest extent possible.

Using Creative Commons Public Licenses

Creative Commons public licenses provide a standard set of terms and conditions that creators and other rights holders may use to share original works of authorship and other material subject to copyright and certain other rights specified in the public license below. The following considerations are for informational purposes only, are not exhaustive, and do not form part of our licenses.

Considerations for licensors: Our public licenses are intended for use by those authorized to give the public permission to use material in ways otherwise restricted by copyright and certain other rights. Our licenses are irrevocable. Licensors should read and understand the terms and conditions of the license they choose before applying it. Licensors should also secure all rights necessary before applying our licenses so that the public can reuse the material as expected. Licensors should clearly mark any material not subject to the license. This includes other CC-licensed material, or material used under an exception or limitation to copyright. More considerations for licensors.
Considerations for the public: By using one of our public licenses, a licensor grants the public permission to use the licensed material under specified terms and conditions. If the licensor’s permission is not necessary for any reason–for example, because of any applicable exception or limitation to copyright–then that use is not regulated by the license. Our licenses grant only permissions under copyright and certain other rights that a licensor has authority to grant. Use of the licensed material may still be restricted for other reasons, including because others have copyright or other rights in the material. A licensor may make special requests, such as asking that all changes be marked or described. Although not required by our licenses, you are encouraged to respect those requests where reasonable. More considerations for the public.

Creative Commons Attribution-ShareAlike 4.0 International Public License

By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.

Section 1 – Definitions.

a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.

b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.

c. BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License.

d. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.

e. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.

f. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.

g. License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.

h. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.

i. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.

j. Licensor means the individual(s) or entity(ies) granting rights under this Public License.

k. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.

l. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.

m. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.

Section 2 – Scope.

a. License grant.

Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:

A. reproduce and Share the Licensed Material, in whole or in part; and

B. produce, reproduce, and Share Adapted Material.
Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
Term. The term of this Public License is specified in Section 6(a).
Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
Downstream recipients.

A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.

B. Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.

C. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).

b. Other rights.

Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
Patent and trademark rights are not licensed under this Public License.
To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.

Section 3 – License Conditions.

Your exercise of the Licensed Rights is expressly made subject to the following conditions.

a. Attribution.

If You Share the Licensed Material (including in modified form), You must:

A. retain the following if it is supplied by the Licensor with the Licensed Material:

i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);

ii. a copyright notice;

iii. a notice that refers to this Public License;

iv. a notice that refers to the disclaimer of warranties;

v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;

B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and

C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.

b. ShareAlike.

In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.

The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.

Section 4 – Sui Generis Database Rights.

Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:

a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;

b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and

c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database.

For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.

Section 5 – Disclaimer of Warranties and Limitation of Liability.

a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.

b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.

c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.

Section 6 – Term and Termination.

a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.

b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:

automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
upon express reinstatement by the Licensor.

For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.

c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.

d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License.

Section 7 – Other Terms and Conditions.

a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.

b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.

Section 8 – Interpretation.

a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.

b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.

c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.

d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.

Creative Commons is not a party to its public licenses. Notwithstanding, Creative Commons may elect to apply one of its public licenses to material it publishes and in those instances will be considered the “Licensor.” The text of the Creative Commons public licenses is dedicated to the public domain under the CC0 Public Domain Dedication. Except for the limited purpose of indicating that material is shared under a Creative Commons public license or as otherwise permitted by the Creative Commons policies published at creativecommons.org/policies, Creative Commons does not authorize the use of the trademark “Creative Commons” or any other trademark or logo of Creative Commons without its prior written consent including, without limitation, in connection with any unauthorized modifications to any of its public licenses or any other arrangements, understandings, or agreements concerning use of licensed material. For the avoidance of doubt, this paragraph does not form part of the public licenses.

Creative Commons may be contacted at creativecommons.org.

Connor Horman's Blog

Summary

LCCC and XLang

Copyright

LCCC - Intro to XLang Design and Examples

Intro to XLang

General Concepts

The xlang crate graph

XLang Plugins

Building IR

Stack Operations in XIR, or how to do interesting things

An Example, the Tiny language lowered to XLang

test1 - A fairly basic example

test2 - A simple executable program

test3 - Adding some Control (Flow)

Comments

Copyright

Rust Compilers and the Rust Spec

Disclaimer

Background of the Rust Spec

Background of Rust Compilers/Implementations

Rust Specification and Rust Implementations

The Future of Rust

Conclusion

Copyright

Copyright Information

Rendering

Creative Commons Attribution-ShareAlike 4.0 International

Creative Commons Attribution-ShareAlike 4.0 International Public License

Section 1 – Definitions.

Section 2 – Scope.

Section 3 – License Conditions.

Section 4 – Sui Generis Database Rights.

Section 5 – Disclaimer of Warranties and Limitation of Liability.

Section 6 – Term and Termination.

Section 7 – Other Terms and Conditions.

Section 8 – Interpretation.