| #include "gc.h" | |
| /** | |
| * Adds destructor to garbage shadow stack. | |
| * | |
| * @param frame is passed automatically by wrapper macro | |
| * @param fn takes one argument | |
| * @param arg is passed to fn(arg) | |
| * @return arg | |
| */ |
See also my tech blog.
- Padraic Edgington's videos
- Design of Digital Circuits, ETH Zurich, Onur Mutlu, Spring 2019
- Basic CPU design course, LC-3, MIPS, FPGA, Vivado, Basys 3
- High Performance Computer Architecture, Georgia Tech CS6290
| /** | |
| * OpenCV video streaming over TCP/IP | |
| * Client: Receives video from server and display it | |
| * by Steve Tuenkam | |
| */ | |
| #include "opencv2/opencv.hpp" | |
| #include <sys/socket.h> | |
| #include <arpa/inet.h> | |
| #include <unistd.h> |
**Note: In all below, slave can also mean interconnect
- Do we really need back-pressure?
- Yes, you absolutely need backpressure. What happens when two masters want to access the same slave? One has to be blocked for some period of time. Some slaves may only be able to handle a limited number of concurrent operations and take some time to produce a result. As such, backpressure is required.
- B and R channel backpressure is required in the case of contention towards the master. If a master makes burst read requests against two different slaves, one of them is gonna have to wait.
- Shouldn't a master be prepared to receive the responses for any requests it issues from the moment it makes the request? Aside from the clock crossing issue someone else brought up, and the interconnect issue at the heart of the use of IDs, why should an AXI master ever stall R or B channels?
- The master should be prepared, but it only has one R and one B input, so it can't re
This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.
It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.
Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2
The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and
| # coin problem: Given an array of coin denominations, | |
| # write a function that returns the minimum number of | |
| # coins that make up a given amount N. There is always | |
| # a coin of value 1 in the coin denominations, so you | |
| # don't have to worry about amounts that cannot possibly | |
| # be formed. | |
| # Example: | |
| # 23, {1,7,9} should return 3 (two 7s + 9); | |
| # 21, {1,7,9} should return 3 (three 7s); |
| WAYLAND_PROTOCOLS=/usr/share/wayland-protocols | |
| # wayland-scanner is a tool which generates C headers and rigging for Wayland | |
| # protocols, which are specified in XML. wlroots requires you to rig these up | |
| # to your build system yourself and provide them in the include path. | |
| xdg-shell-protocol.h: | |
| wayland-scanner server-header \ | |
| $(WAYLAND_PROTOCOLS)/stable/xdg-shell/xdg-shell.xml $@ | |
| xdg-shell-protocol.c: xdg-shell-protocol.h |
| # perform a fresh install of Ubuntu 17.10 | |
| # upgrade the kernel to v4.13.10 | |
| mkdir ~/kernel-v4.13.10 | |
| cd ~/kernel-v4.13.10 | |
| wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.10/linux-headers-4.13.10-041310_4.13.10-041310.201710270531_all.deb | |
| wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.10/linux-headers-4.13.10-041310-generic_4.13.10-041310.201710270531_amd64.deb | |
| wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.10/linux-image-4.13.10-041310-generic_4.13.10-041310.201710270531_amd64.deb | |
| sudo dpkg -i *.deb |
After checking multiple tutorials I had to take pieces from each of the following to get this to work on my Win10 system:
- https://www.howtogeek.com/165268/how-to-add-open-powershell-here-to-the-context-menu-in-windows/
- https://www.tenforums.com/tutorials/60175-open-powershell-window-here-context-menu-add-windows-10-a.html
Basically it uses the steps from the first article, but under the background path from the second article.
Neither article on its own worked for me.
Steps: