![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
---
l5 has .ethereum
---
" Side note: The .NET framework did break backwards compatibility when moving from 1.0 to 2.0, precisely so that support for generics could be added deep into the runtime, i.e. with support in the IL. "
---
could our LONG format be too complicated? Maybe all we really want is a simple hierarchy with tag-length-value (TLV) nodes?
---
" RISC-V ISA Overview The RISC-V ISA is defined as a base integer ISA, which must be present in any implementation, plus optional extensions to the base ISA. The base integer ISA is very similar to that of the early RISC processors except with no branch delay slots and with support for optional variable-length instruction encodings. The base is carefully restricted to a minimal set of instructions sufficient to provide a reasonable target for compilers, assemblers, linkers, and operating systems (with additional supervisor-level operations), and so provides a convenient ISA and software toolchain “skeleton” around which more customized processor ISAs can be built ... Each base integer instruction set is characterized by the width of the integer registers and the corresponding size of the user address space. There are two primary base integer variants, RV32I and RV64I, described in Chapters 2 and 4, which provide 32-bit or 64-bit user-level address spaces respectively. Hardware implementations and operating systems might provide only one or both of RV32I and RV64I for user programs. Chapter 3 describes the RV32E subset variant of the RV32I base instruction set, which has been added to support small microcontrollers ... The base RISC-V ISA has fixed-length 32-bit instructions that must be naturally aligned on 32-bit boundaries. However, the standard RISC-V encoding scheme is designed to support ISA extensions with variable-length instructions, where each instruction can be any number of 16-bit instruction parcels in length and parcels are naturally aligned on 16-bit boundaries. ... We chose little-endian byte ordering for the RISC-V memory system because little-endian sys- tems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more nat- ural for hardware designers ... Chapter 2 RV32I Base Integer Instruction Set, Version 2.0
This chapter describes version 2.0 of the RV32I base integer instruction set. Much of the commen- tary also applies to the RV64I variant. RV32I was designed to be sufficient to form a compiler target and to support modern operating system environments. The ISA was also designed to reduce the hardware required in a mini- mal implementation. RV32I contains 47 unique instructions, though a simple implementation might cover the eight SCALL/SBREAK/CSRR* instructions with a single SYSTEM hardware instruction that always traps and might be able to implement the FENCE and FENCE.I in- structions as NOPs, reducing hardware instruction count to 38 total. RV32I can emulate almost any other ISA extension (except the A extension, which requires additional hardware support for atomicity).
...
Figure 2.1 shows the user-visible state for the base integer subset. There are 31 general-purpose registers x1 – x31 , which hold integer values. Register x0 is hardwired to the constant 0. There is no hardwired subroutine return address link register, but the standard software calling convention uses register x1 to hold the return address on a call. For RV32, the x registers are 32 bits wide, and for RV64, they are 64 bits wide. This document uses the term XLEN to refer to the current width of an x register in bits (either 32 or 64). There is one additional user-visible register: the program counter pc holds the address of the current instruction. The number of available architectural registers can have large impacts on code size, performance, and energy consumption. Although 16 registers would arguably be sufficient for an integer ISA running compiled code, it is impossible to encode a complete ISA with 16 registers in 16-bit instructions using a 3-address format. Although a 2-address format would be possible, it would increase instruction count and lower efficiency. We wanted to avoid intermediate instruction sizes (such as Xtensa’s 24-bit instructions) to simplify base hardware implementations, and once a 32-bit instruction size was adopted, it was straightforward to support 32 integer registers. A larger number of integer registers also helps performance on high-performance code, where there can be extensive use of loop unrolling, software pipelining, and cache tiling. For these reasons, we chose a conventional size of 32 integer registers for the base ISA. Dy- namic register usage tends to be dominated by a few frequently accessed registers, and regfile im- plementations can be optimized to reduce access energy for the frequently accessed registers [26]. The optional compressed 16-bit instruction format mostly only accesses 8 registers and hence can provide a dense instruction encoding, while additional instruction-set extensions could support a much larger register space (either flat or hierarchical) if desired. For resource-constrained embedded applications, we have defined the RV32E subset, which only has 16 registers (Chapter 3). " -- [1]
---
https://chrissherlock1.gitbooks.io/inside-libreoffice/content/system_abstraction_layer.html
---
The Michelson language (see my notes in [[plbook-plChMiscIntermedLangs?]] or their PDF) is a nice little low-level typed functional stack-based language. Too high level for Boot but maybe good for Ovm.
Except that i think that their regexp-based macro-defined instruction classes (P(A*AI)+R, C[AD]+R, DII+P) are too powerful for a low-level language (although cool for a HLL).
---
[2]:
"
---
naasking 1 day ago [-]
Except you can't sandbox or virtualize the clock because mx_time_get() doesn't require a handle, which makes timing attacks easier.
You also can't sandbox event and channel creation for the same reason. It looks like these can also DoS? the kernel. In general, any operation you can perform without a handle tends to be subject to DoS? and you can't virtualize it. They're also subject to a different access control policy than the rest of the system which is based around handles.
And it's not really necessary. Just reserve the first few handles in a process table for a clock handle, a channel constructor/factory handle and an event constructor/factory handle, and now these operations can be fully virtualized and they aren't subject to DoS? because they can be rate-limited or at least traced back to specific handles which can be revoked.
Without tracing every operation to a handle, you have to pollute your model with more infrastructure to track this information, as with channels and events in Fuschia.
[1] https://fuchsia.googlesource.com/magenta/+/master/docs/conce...
reply
" Fuchsia
HomeGetting StartedGlossary
Sandboxing
This document describes how sandboxing works in Fuchsia. An empty process has nothing
On Fuchsia, a newly created process has nothing. A newly created process cannot access any kernel objects, cannot allocate memory, and cannot even execute code. Of course, such a process isn't very useful, which is why we typically create processes with some initial resources and capabilities.
Most commonly, a process starts executing some code with an initial stack, some command line arguments, environment variables, a set of initial handles. One of the most important initial handles is the PA_VMAR_ROOT, which the process can use to map additional memory into its address space. Namespaces are the gateway to the world
Some of the initial handles given to a process are directories that the process mounts into its namespace. These handles let the process discover and communicate with other processes running on the system, including file systems and other servers. See Namespaces for more details.
The namespace given to a process strongly influences how much of the system the process can influence. Therefore, configuring the sandbox in which a process runs amounts to configuring the process's namespace. Archives and namespaces
In our current implementation, a process runs in a sandbox if its binary is contained in an archive (i.e., a FAR). As the package manager evolves, these details are likely to change.
An application run from an archive is given access to two namespaces by default:
/svc, which is a bundle of services from the environment in which the application runs.
/pkg, which is a read-only view of the archive containing the application.A typical application will interact with a number of services from /svc in order to play some useful role in the system.
The far command-line tool can be used to inspect packages installed on the system. For example, far list --archive=/system/pkgs/root_presenter will list the contents of the root_presenter archive:
$ far list --archive=/system/pkgs/root_presenter bin/app data/cursor32.png meta/sandbox
To access these resources at runtime, a process can use the /pkg namespace. For example, the root_presenter can access cursor32.png using the absolute path /pkg/data/cursor32.png. Configuring additional namespaces
If a process requires access to additional resources (e.g., device drivers), the package can request access to additional names by including a sandbox metadata file in its package. For example, the following meta/sandbox file requests direct access to the framebuffer driver:
{ "dev": [ "class/framebuffer" ] }
In the current implementation, the AppMgr? grants all such requests, but that is likely to change as the system evolves. Building an archive
To build a package, use the package() macro in gn defined in packages/packages.gni. Specifically, to create a Fuchsia Archive (FAR) for your package (which will trigger sandboxing), set the archive flag to true. See the documentation for the package() macro for details about including resources