RISC-V Bare Metal Programming - Chapter 5: It's a Trap!

Submitted by MarcAdmin on Tue, 12/10/2019 - 21:36
Up to this point, the RISC-V tutorial has focused on single applications running on a single hardware thread. The application's environment was composed of the processor's state and memory map. The processor state was controlled via assembly instructions, and the memory map was defined at build time via a linker script. However, modern systems are almost always multiprogrammed and will execute many applications concurrently (by interleaving their instructions in a single stream). Moreover, multiple hardware threads are common, allowing application instructions to execute simultaneously. This workflow requires a lot more care to ensure correctness and proper separation of memory. This idea was touched upon briefly in chapter 4 while discussing the A extension which provides atomic memory operations that were used to define synchronization primitives. In addition to memory synchronization, the application must control the execution environment of all of the active hardware threads, this chapter will explore the mechanisms available for this purpose.

Tags

RISC-V Bare Metal Programming - Chapter 4: Another Brick in the Wall

Submitted by MarcAdmin on Sat, 11/30/2019 - 01:41
Chapter 3 of this RISC-V bare metal tutorial studied the linking process and how a developer can control where code and data are placed in memory. Constants, initialized variables and uninitialized variables were defined and explicitly positioned in RAM as prescribed by a linker script. The running example program was updated to read operands from RAM to perform its task, and subsequently store the result in a different location in RAM. However, up to this point only the base RV64I instruction set has been used. This chapter will explore some of the standard extensions available in the RISC-V ISA.

Tags

RISC-V Bare Metal Programming Chapter 3: A Link to the Past

Submitted by MarcAdmin on Tue, 11/12/2019 - 12:27

Previous chapters of the RISC-V bare metal programming tutorial have focused primarily on the assembler. In chapter 2, assembler directives were discussed along with their relationship to the positioning of code in an executable. The various sections of where code and data reside have well defined semantics in the Executable and Linkable Format specification. In this chapter, these semantics and the linking process will be examined in more detail.

Tags

RISC-V Bare Metal Programming Chapter 2: OpCodes Assemble!

Submitted by MarcAdmin on Wed, 11/06/2019 - 08:03
The previous chapter of this tutorial went over the steps required to setup a RISC-V development environment to create a program that runs on a bare metal VirtIO board using QEMU. Even though the example program – which calculates the sum two integers – was written in RISC-V assembly, no prior knowledge was required to follow along. This chapter will dive into the details of RISC-V assembly language as well as expand on what exactly is happening at each step of the development. The topics covered in this chapter will include an overview of the RISC-V architecture, its assembly instructions, pseudo-instructions, and directives.

Tags

RISC-V Bare Metal Programming Chapter 1: The Setup

Submitted by MarcAdmin on Fri, 11/01/2019 - 21:27
In this tutorial, we will walk through the process of building and running a RISC-V program on bare metal hardware; or more specifically emulated hardware. I assume that the reader is familiar with the GNU toolchain and basic C programming. Assembly experience is useful but should not be required to follow along.

Tags

Game, Set, Match

Submitted by MarcAdmin on Tue, 08/21/2018 - 08:58
One of the motivations in creating the Didactronic Framework was to learn new technology. Many ports of the framework have been started including using Python, Java, Clojure, and most recently Rust. Rust was an interesting options because of its promise of speed, safety and expressiveness. It seemed a good middle ground between imperative and functional programming. Since this is a completely new language and development paradigm for me (being primarily a C and Lisp hacker), the Rust framework will need to be refined over time to make use of the various constructs that are unique to that language. One such construct is the match form.

Design of the Didactronic Toolkit.

Submitted by MarcAdmin on Thu, 07/05/2018 - 22:38
The Didactronic Toolkit came about as a way to investigate ideas about formulating reinforcement learning problems using group theory. Its name, didactronic, is a contraction of the "didact" part of the word didactic, appended with the suffix "-tronic".
didactic
a) designed or intended to teach, b) intended to convey instruction and information as well as pleasure and entertainment didactic poetry.
-tronic
Greek: a suffix referring to a device, tool, or instrument; more generally, used in the names of any kind of chamber or apparatus used in experiments.
Therefore the term Didactronic signifies an instrument or apparatus intended to teach or convey instruction to an agent through experiments; this is the essence of reinforcement learning. The Didactronic Toolkit is meant to provide the basic tools to build such an instrument for an arbitrary task. However, since the toolkit is meant to be independent of domain, it must be both useful enough to simplify the task while being generic enough not to constrain it. The goal of this article is to distill reinforcement learning into its most basic elements to provide insight into the design philosophy behind the toolkit. The secondary objective of this work is to provide a vehicle for learning the Rust language. To that end, the Didactronic Toolkit will be re-implemented as a crate in Rust.

Play Tic-tac-toe with Arthur Cayley! Part Two: Expansion

Submitted by MarcAdmin on Wed, 02/17/2016 - 23:39

In part 1 of this series, the Tic-tac-toe reinforcement learning task was expressed as a Combinatorial Group with the hypothesis that the expansion of the group into a Cayley Graph could be used to learn its associated game tree. In this instalment, the expansion of the group into a Caley Graph will be examined in a bit more detail. Initially, the Tic-tac-toe group will be set aside in favour of a simpler domain which will offer a more compact and pedagogical representation. However, the expansion of the Tic-tac-toe group should follow the same process, this article will circle back to the Tic-tac-toe domain to highlight the equivalences which should ensure that this is so.

Tags

Play Tic-tac-toe with Arthur Cayley!

Submitted by MarcAdmin on Fri, 02/05/2016 - 22:51

Tic-tac-toe, (or noughts and crosses or Xs and Ox), is a turn-based game for two players who alternately tag the spaces of a $3 \times 3$ grid with their respective marker: an X or an O. The object of the game is to place three markers in a row, either horizontally, vertically, or diagonally. Given only the mechanics of Tic-tac-toe, the game can be expressed as Combinatorial Group by defining a set $A$ of generators $\{a_i\}$ which describe the actions that can be taken by either player. The Cayley Graph of this group can be constructed which will express all the possible ways the game can be played. Using the Cayley Graph as a model, it should be possible to learn the Tic-tac-toe game tree using dynamic programming techniques (hint: the game tree is a sub-graph of the Cayley Graph).

Tags

Subscribe to