<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Shironeko Labs</title>
    <link>https://www.shironekolabs.com/</link>
    <description>Recent content on Shironeko Labs</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 31 May 2021 15:33:42 +0900</lastBuildDate>
    
	<atom:link href="https://www.shironekolabs.com/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>SuperRT Source Release</title>
      <link>https://www.shironekolabs.com/posts/superrt-source-release/</link>
      <pubDate>Mon, 31 May 2021 15:33:42 +0900</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/superrt-source-release/</guid>
      <description>It took a bit longer than I&amp;rsquo;d hoped to tidy things up, but the SuperRT source code is finally released.
There&amp;rsquo;s a lot more detail in the readme file included with the code, but in broad strokes it&amp;rsquo;s probably mostly of academic interest rather than useful in any practical way - hopefully it will be of interest to anyone curious about the inner workings of the demo.</description>
    </item>
    
    <item>
      <title>Efficient approximate square roots and division in Verilog</title>
      <link>https://www.shironekolabs.com/posts/efficient-approximate-square-roots-and-division-in-verilog/</link>
      <pubDate>Sat, 23 Jan 2021 11:51:27 +0900</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/efficient-approximate-square-roots-and-division-in-verilog/</guid>
      <description>SuperRT uses, for the most part, fairly simple maths operations - integer addition and multiplication - which are natively supported by Verilog (and can be offloaded to DSPs in some cases). There are, however, some places where it inevitably has to do more complex operations - notably divides and square roots (he hardware side avoids the need for any sine/cosine calculations by formatting the incoming data in such a way that the SNES CPU takes those on).</description>
    </item>
    
    <item>
      <title>The SuperRT Tools</title>
      <link>https://www.shironekolabs.com/posts/the-superrt-tools/</link>
      <pubDate>Wed, 23 Dec 2020 19:33:23 +0900</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/the-superrt-tools/</guid>
      <description>Update 31th May 2021: The source code for SuperRT has now been released.
 One thing I learnt very quickly when I started looking at FPGA design was that debugging is hard. Simulation tools exist but from what I&amp;rsquo;ve seen they are slow, don&amp;rsquo;t replicate all the quirks of hardware, and for situations like this where interfacing to external devices is an integral part of the design don&amp;rsquo;t seem to be a good option - to be honest, I gave up pretty quickly on getting anything meaningful out of them and stuck to testing solely on the hardware itself (I fully expect that a large part of this is down to my not really understanding how they are supposed to be used, though - remember that this is my first FPGA project ever and weigh my opinions accordingly!</description>
    </item>
    
    <item>
      <title>SuperRT</title>
      <link>https://www.shironekolabs.com/posts/superrt/</link>
      <pubDate>Sun, 13 Dec 2020 15:13:19 +0900</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/superrt/</guid>
      <description>Video links for this article:
 Short trailer Walkthrough and technical details   Update 31th May 2021: The source code for SuperRT has now been released.
 I&amp;rsquo;m pleased to finally have some results to show for a project I&amp;rsquo;ve been working on in my spare time for the last year or so.
The idea originated when I was trying to think of an interesting idea for a project to help me learn Verilog and FPGA design, and the notion of building a simple raytracer came to mind (partly inspired by a scarily smart friend of mine who is building his own GPU).</description>
    </item>
    
    <item>
      <title>The Evaluation Stack</title>
      <link>https://www.shironekolabs.com/posts/the-evaluation-stack/</link>
      <pubDate>Wed, 25 Sep 2019 17:48:36 +0900</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/the-evaluation-stack/</guid>
      <description>A concept which took me a little while to get my head around the first time I encountered it in the CLR is that of the &amp;ldquo;evaluation stack&amp;rdquo;, so I thought I&amp;rsquo;d write a little bit to summarise how it works (or, well, how I think it works, which may be slightly different - let me know if I&amp;rsquo;ve got anything wrong!).
In terms of how they execute code, the vast majority of CPUs are &amp;ldquo;register-based&amp;rdquo;, which is to say that instructions reference data stored in a fixed number of registers held within the chip itself.</description>
    </item>
    
    <item>
      <title>Contextual and context-free microcode</title>
      <link>https://www.shironekolabs.com/posts/instruction-context/</link>
      <pubDate>Mon, 02 Sep 2019 18:42:32 -0700</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/instruction-context/</guid>
      <description>A key part of Catnip&amp;rsquo;s architecture is the use of internal microcode. As an intermediate step prior to execution, IL instructions are converted into this microcode, which is then what actually gets executed by the interpreter (or subsequently converted into native code).
The primary reason for this is that IL instructions are heavily contextual - for example, the ADD instruction may be adding integers or floating point values in either 32 bit or 64 bit mode.</description>
    </item>
    
    <item>
      <title>Concurrent garbage collection</title>
      <link>https://www.shironekolabs.com/posts/concurrent-garbage-collection/</link>
      <pubDate>Wed, 31 Jul 2019 14:53:09 +0900</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/concurrent-garbage-collection/</guid>
      <description>In the previous post I looked a little bit at the fundamental principles of garbage collection, and now I’d like to talk a little about concurrent garbage collection and why it’s a much harder proposition.
Up until now our assumption has been that whilst the GC is running the data in the heap is constant - this can either be because the application has been paused (and thus nothing is modifying it), or because some mechanism has been used to take a snapshot of the heap in a consistent state (we’ll talk a little about that later).</description>
    </item>
    
    <item>
      <title>Garbage collection basics</title>
      <link>https://www.shironekolabs.com/posts/garbage-collection-basics/</link>
      <pubDate>Sat, 01 Jun 2019 14:53:09 +0900</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/garbage-collection-basics/</guid>
      <description>This is the start of a semi-regular series of articles I&amp;rsquo;m hoping to write, time-permitting, looking at interesting things I&amp;rsquo;ve run into, discovered, or failed miserably to comprehend whilst working on Catnip. A lot of this is going to be a bit ad-hoc, so apologies in advance for any errors or omissions - criticism or corrections are both greatly appreciated at contact@shironekolabs.com!
One of the more interesting concepts in writing a C# runtime, or for that matter managed languages in general, is that of garbage collection.</description>
    </item>
    
    <item>
      <title>Introducing Catnip, a C# runtime for games</title>
      <link>https://www.shironekolabs.com/posts/introducing-catnip/</link>
      <pubDate>Fri, 22 Mar 2019 23:42:32 -0700</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/introducing-catnip/</guid>
      <description>Whilst I&amp;rsquo;m not quite in a position to share lots more details and/or code yet, I thought I&amp;rsquo;d write a little bit about a project I&amp;rsquo;ve been working on for some time now.
It&amp;rsquo;s called &amp;ldquo;Catnip&amp;rdquo; (sorry, cat-related project names seem to happen a lot around me!), and it&amp;rsquo;s a new implementation of the Common Language Runtime - the foundation used by C# and other languages in what is often referred to as the &amp;ldquo;.</description>
    </item>
    
    <item>
      <title>The Catnip Prototype</title>
      <link>https://www.shironekolabs.com/posts/the-catnip-prototype/</link>
      <pubDate>Fri, 22 Mar 2019 13:42:32 -0700</pubDate>
      
      <guid>https://www.shironekolabs.com/posts/the-catnip-prototype/</guid>
      <description>So having talked a bit in my previous post about the rationale behind Catnip, I&amp;rsquo;d like to jump forward and introduce some results. Catnip is very much still a prototype, and I&amp;rsquo;d like to get more of the rough edges off before I actually release any code, but I&amp;rsquo;ve got an interesting little demo that shows off some of the key features at work.
This is Catnip running a little &amp;ldquo;Wolfenstein 3D&amp;rdquo;-style demo written in pure C# on a Gameboy Advance Micro (which, for reference, has a 16Mhz CPU and 256Kb of RAM):</description>
    </item>
    
  </channel>
</rss>