You can call into Cocoa Touch APIs to use methods and properties that are not built into the framework by using the Declare command. To create a Declare statement you first need to track down the API you want to use in Apple’s documentation: Apple Developer Documentation. Most of the time you will reference the Foundation and UIKit libraries, but there are many other libraries as well. Xojo Declares use the Objective-C names so be sure to refer to those in the documentation rather than the Swift naming.
Comments closedAuthor: Paul Lefebvre
The linker is not technically part of the compiler, but it is needed to make a completed app. The purpose of the linker is to combine (link) all the various bits and pieces of machine code created by the compiler along with the necessary information to create a runnable app for the OS.
This is the ninth and final post in our Compiler series. Previous posts:
- LLVM Everywhere
- Compilers 101 – Overview and Lexer
- Compilers 102 – Parser
- Compilers 103 – Semantic Analyzer
- Compilers 104 – IR Generation
- Compilers 105 – Back End Overview
- Compilers 106 – Optimizer
- Compilers 107 – Optimizer Loop Unrolling
- Compilers 108 – Code Generation
Code generation is one of the last steps of the compiler. This is where the compiler emits actual machine code for the IR that was previously created.
This is the eighth post in our Compiler series. Other posts:
- LLVM Everywhere
- Compilers 101 – Overview and Lexer
- Compilers 102 – Parser
- Compilers 103 – Semantic Analyzer
- Compilers 104 – IR Generation
- Compilers 105 – Back End Overview
- Compilers 106 – Optimizer
- Compilers 107 – Optimizer Loop Unrolling
The last post covered optimization in general. In this post you’ll look at a specific optimization called “loop unrolling”.
This is the seventh post in our Compiler series. Other posts:
- LLVM Everywhere
- Compilers 101 – Overview and Lexer
- Compilers 102 – Parser
- Compilers 103 – Semantic Analyzer
- Compilers 104 – IR Generation
- Compilers 105 – Back End Overview
- Compilers 106 – Optimizer
As the old joke goes, “There are 10 types of people, those that understand how binary numbers work and those that don’t.” Let’s get you into the “understand” group.
Comments closed
An optimizer “improves” the IR, but that can mean a lot of different things. Improve could mean “run faster” or “use less memory”. Or perhaps you want to optimize for memory access time because CPUs are so fast it is sometimes more efficient to repeatedly calculate something rather than calculate it once, store it and access it later.
This is the sixth post in our Compiler series. Previous posts:
- LLVM Everywhere
- Compilers 101 – Overview and Lexer
- Compilers 102 – Parser
- Compilers 103 – Semantic Analyzer
- Compilers 104 – IR Generation
- Compilers 105 – Back End Overview
Once the front end has done its work its time for the back end components to take over.
This is the fifth in our compiler series and the first on the back end. We covered the parts of the compiler that are called the front end in these posts:
- LLVM Everywhere
- Compilers 101 – Overview and Lexer
- Compilers 102 – Parser
- Compilers 103 – Semantic Analyzer
- Compilers 104 – IR Generation
Now that the Semantic Analyzer has verified that the code is actually correct and created syntax trees, it’s time to talk about IR generation.
This is the fourth post in our Compiler series. Other posts:
- LLVM Everywhere
- Compilers 101 – Overview and Lexer
- Compilers 102 – Parser
- Compilers 103 – Semantic Analyzer
The Semantic Analyzer is the real heart of the compiler. Its job is to validate code and figure out what the code actually means. Essentially it validates that the code is semantically correct.
This is the third post in our Compiler series. Previous posts:
Comments closedThe Xojo community is vibrant and active, with all kinds of clever, open-source software being created for iOS, desktop, web and Raspberry Pi. By my latest count, there are at least 80 open-source projects for Xojo on GitHub and other places!
Comments closed