Chess and 18th Century artificial intelligence (2013)

www.bbc.com - Comments

The operator, a man named Johann Maelzel, would assemble a paying audience, open the doors of the lower cabinet and show an impressively whirring clockwork mechanism that filled the inner compartments beneath the seated figure. Then he would close the cabinet, and invite a challenger to play chess. The automaton - the robot, as we would say now - would gaze at the opponent's move, ponder, then raise its mechanical arm and make a stiff but certain move of its own.

The thing was a sensation.

Before it was destroyed by fire in New York in the 1850s, it played games with everyone from Benjamin Franklin to, by legend at least, Napoleon Bonaparte. Artificial intelligence, the 18th Century thought, had arrived, wearing a fez and ticking away like Captain Hook's crocodile.

I should rush to say that, of course, the thing was a fraud, or rather, a trick - a clever magician's illusion. A sliding sled on well-lubricated castors had been fitted inside the lower cabinet and the only real ingenuity was that this let a hidden chess player glide easily, and silently, into a prone position inside. There was just a lot more room to hide in the cabinet than all that clockwork machinery suggested.

Now, the Turk fascinates me for several reasons. First, because it displays an odd, haunting hole in human reasoning. Common sense should have told the people who watched and challenged it that for the Turk to have really been a chess-playing machine, it would have had to have been the latest in a long sequence of such machines. For there to be a mechanical Turk who played chess, there would have had to have been, 10 years before, a mechanical Greek who played draughts.

It's true that the late 18th Century was a great age of automatons, machines that could make programmed looms weave and mechanical birds sing - although always the same song, or tapestry, over and over. But the deeper truth that chess-playing was an entirely different kind of creative activity seemed as obscure to them as it seems obvious to us now.

You could have invented fractional cascading

blog.ezyang.com - Comments

Suppose that you have k sorted arrays, each of size n. You would like to search for single element in each of the k arrays (or its predecessor, if it doesn't exist).

/img/fractional-cascading/intro.png

Obviously you can binary search each array individually, resulting in a O(k\lg n) runtime. But we might think we can do better that: after all, we're doing the same search k times, and maybe we can "reuse" the results of the first search for later searches.

Here's another obvious thing we can do: for every element in the first array, let's give it a pointer to the element with the same value in the second array (or if the value doesn't exist, the predecessor.) Then once we've found the item in the first array, we can just follow these pointers down in order to figure out where the item is in all the other arrays.

/img/fractional-cascading/pointers.png

But there's a problem: sometimes, these pointers won't help us at all. In particular, if a later lists is completely "in between" two elements of the first list, we have to redo the entire search, since the pointer gave us no information that we didn't already know.

/img/fractional-cascading/pointer-fail.png

So what do we do? Consider the case where k = 2; everything would be better if only we could guarantee that the first list contained the right elements to give you useful information about the second array. We could just merge the arrays, but if we did this in the general case we'd end up with a totally merged array of size kn, which is not so good if k is large.

But we don't need all of the elements of the second array; every other item will do!

/img/fractional-cascading/one-level.png

Let's repeatedly do this. Take the last array, take every other element and merge it into the second to last array. Now, with the new second to last array, do this to the next array. Rinse and repeat. How big does the first array end up being? You can solve the recurrence: T(k) = n + T(k-1)/2, which is the geometric series n + n/2 + n/4 + n/8 + \ldots = 2n. Amazingly, the new first list is only twice as large, which is only one extra step in the binary search!

/img/fractional-cascading/multi-level.png

What we have just implemented is fractional cascading! A fraction of any array cascades up the rest of the arrays.

There is one more detail which has to be attended to. When I follow a pointer down, I might end up on an element which is not actually a member of the current array (it was one that was cascaded up). I need to be able to efficiently find the next element which is a member of the current array (and there might be many cascaded elements jammed between it and the next member element, so doing a left-scan could take a long time); so for every cascaded element I store a pointer to the predecessor member element.

/img/fractional-cascading/extra-pointers.png

Fractional cascading is a very useful transformation, used in a variety of contexts including layered range trees and 3D orthogonal range searching. In fact, it can be generalized in several ways. The first is that we can cascade some fixed fraction α of elements, rather than the 1/2 we did here. Additionally, we don't have to limit ourselves to cascading up a list of arrays; we can cascade up an arbitrary graph, merging many lists together as long as we pick α to be less than 1/d, where d is the in-degree of the node.

/img/fractional-cascading/graph.png

Exercise. Previously, we described range trees. How can fractional cascading be used to reduce the query complexity by a factor of O(\lg n)?

Exercise. There is actually another way we can setup the pointers in a fractionally cascaded data structure. Rather than have downward pointers for every element, we only maintain pointers between elements which are identical (that is to say, they were cascaded up.) This turns out to be more convenient when you are constructing the data structure. However, you now need to maintain another set of pointers. What are they? (Hint: Consider the case where a search lands on a non-cascaded, member element.)

Transforming a QLC SSD into an SLC SSD

theoverclockingpage.com - Comments

In today’s article, we’re embarking on something unprecedented! We’ll guide you step by step through the process of transforming an SSD equipped with QLC NANDs into an SLC SSD, significantly enhancing its durability and overall performance!

Especification of the DUT SSD:

SSD Lineup US

The SSD I chose is a Crucial BX500, which we’ve tested numerous times both on our website and on my YouTube channel.

ATENTION: BEFORE YOU CONTINUE READING!!!

Firstly, this procedure is safer than overclocking, but it still requires caution. Only proceed if you are genuinely interested, as I cannot be held responsible if any steps are executed incorrectly. I will explain as clearly as possible to minimize any misunderstandings.

This voids the warranty of any SSD. AND REMEMBER, WHEN FLASHING THE FIRMWARE TO THE SSD, ALL DATA WILL BE ERASED, so be sure to back up your devices before proceeding with anything.

NECESSARY TOOLS

To perform this procedure, it was necessary to use an adapter SATA to USB 3.0 adapter with the Jmicron JMS578 Bridge Chip model.

Ferramenta SSD Card Opener 4image 2

In addition to, we also need a clamp to perform the short on the ROM/Safe Mode terminals on the SSD’s PCB.

Technical Specs

Before we move on to the tutorial, let’s analyze this SSD a little further.

Controller

The SSD controller is responsible for handling all data management tasks, including over-provisioning and garbage collection, among other background functions. Naturally, this contributes to the SSD’s overall performance.

ssd crucial bx500 500gb controlador

In this project, the SSD utilizes the Silicon Motion controller model SM2259XT2, which is a new variant of the SM2259XT.

In this case, it’s a single-core controller, meaning it has one main core responsible for managing the NANDs, with a 32-bit ARC architecture, not ARM as we’re accustomed to. This controller has an operating frequency up to 550 MHz, but as we’ll see in the following image, in this project, it was operating at 437.5 MHz.

This controller also supports up to 2 communication channels with a bus speed of up to 800 MT/s, where each of these channels supports up to 8 Chip Enable commands, allowing the controller to communicate with up to 16 Dies simultaneously using the interleaving technique.

Screenshot 2024 03 02 111225

What was different from its predecessor, the SM2259XT, which had 4 channels and 4 C.E. supporting a maximum of 16 dies.

DRAM Cache or H.M.B.

Every top-of-the-line SSD aiming to deliver consistent high performance requires a buffer to store its mapping tables (Flash Translation Layer or Look-up table). This enables better random performance and responsiveness.

Being a DRAM-Less SATA SSD, it doesn’t support Host Memory Buffer (HMB) technology.

NAND Flash

Regarding its storage integrated circuits, the 500GB SSD has 2 NAND flash chips labeled “NY240,” which when decoded yield the NANDs “MT29F2T08GELCEJ4-QU:C” from the American manufacturer Micron, model N48R Media Grade. In this case, they are 1Tb (128GiB) dies containing 176 layers of data and a total of 195 gates, resulting in an array efficiency of 90.2%.

ssd crucial bx500 500gb nand flash

In this SSD, each NAND Flash contains 2 dies with 1Tb of density, totaling 256GB per NAND, resulting in a total of 500GB. They communicate with the controller using a bus speed of 262.5 MHz (525 MT/s), which is considerably below what the NANDs are capable of. These N48R dies are capable of operating at 800 MHz (1600 MT/s).

There are several reasons why they might be running so low, such as the manufacturer opting to reduce power consumption and heat. Or even this batch of NAND Flash not being able to pass Micron’s Quality Control at higher frequencies and ends up being sold cheaper or perhaps has a lower endurance as well, which generally results in lower NAND costs, enabling SSDs like this to have a very low price.

SOFTWARE UTILIZED FOR THIS PROJECT

As this is a Silicon Motion controller, we will be using a mass production tool from them, known as MPTools. It’s worth noting that these softwares are NOT provided by the manufacturers but are LEAKED by individuals with access, and posted on Russian or Chinese forums.

image 1

For this project, we will use the “SMI SM2259XT2 MPTool FIMN48 V0304A FWV0303B0“, which needs to be compatible with both the controller and the NAND Flash, and this tool allows us to do that.

image 2

Before making any modifications, we need to retrieve certain parameters from the SSD to preserve them. These values in the software are a preset from another SSD that may have different parameters. We need to obtain the following parameters:

  • Flash IO Driving with it’s subivisons
  • Flash Control Driving
  • Flash DQS/Data Driving

These parameters use hexadecimal values and must be changed according to the desired speed that we will configure for the SSD.

We also have many more parameters such as:

  • Control ODT (On-die Termination)
  • Flash ODT (On-die Termination)
  • Schmitt Window Trigger

To get these parameters, we need to go to the main screen of MPTools as shown below:

image 3

And then we’ll click on “Scan,” which will scan all compatible disks in the system:

image 4

After this, the SSD will be shown on port 1 if everything has gone smoothly so far, remembering that it’s not necessary to put the SSD in Safe Mode/ROM Mode yet.

image 5

Now we double-click on this Blue Name “Ready (FW: M6CR061, MN48R)“, which, when clicked twice, will open this new screen with SSD information.

image 6

Then we should click on both Card mode and CID Settings to see all the parameters that the SSD comes with from the factory.

image 7

After noting these parameters, we also see here the speed of the controller and the NAND, which for the sake of a fair comparison, we will leave at these same frequencies.

Screenshot 2024 03 02 111225 Copy 1Screenshot 2024 03 02 111303 Copy 1

Applying Configurations

Initially, we should click on the “Edit Config” button in the top right corner, and the default password is “space 2x,” which is literally ” “.

Screenshot 2024 03 06 142821

After enabling the options to configure the SSD, let’s start by giving a name to this project. In the “Model Name:” field, we’ll enter the name that the SSD will have. This one was named “SSD SLC Test.”

Next, we’ll add a tag to this new firmware. In the red rectangle number 3, we’ll go to the “Firmware Version:” field and enter whatever we desire. I used “SSD-SLC” as an example.

Next, we arrive at one of the most crucial parts, the section on signal integrity, as all these other parameters are sensitive and must be adjusted precisely.

Let’s start with the top 2 parameters, “Flash Control Driving (hex)” and “Flash DQS/Data Driving (Hex)“. As we saw in the previous images, these parameters come with values of 66 in hexadecimal, so we will keep them. These 2 parameters can be found in the images below:

image 8

After configuring these 2, let’s move on to the frequencies. As we can see in the image below, we take these 2 values and set them. The CPU in this software came by default at 500 MHz while the NAND at 250 MHz. The NAND will increase the clock slightly and the CPU will decrease, I will not overclock here for a fair comparison. Next, we’ll leave the Output driving at 03H, which is the signal closest to 04H that the SSD had.

image 10

Next, we have the last 3 settings to resolve: Flash ODT, Control ODT, and Schmitt Window. In this case, we apply the values circled in red in each of these parameters in their respective fields.

image 16

Good, here we have reached the end of another stage of this procedure. And we begin the next following step, which is the modification of the software. Because by default, this version of MPTools would not support this modification.

Initially, we need to go to the directory of this program in the “UFD_MP” folder located in the root directory.

image 19

Inside this folder, we should look for the file named “Setting.set,” which is a configuration file of MPTools. Let’s open it using the Windows Notepad.

image 20

With the file open, we’ll make 2 modifications, the first one being in the section “[Function]“, where we have the configuration named “ENFWTAG=1,” which we should change its logical level from 1 to 0.

image 22

The other configuration is in the category “[Option]“, where we will add one more extra command line. This command is as follows: “EnSLCMode=1“. So after that, we save the file and reopen the MPTools.

image 23

With MPTools open, we can see that in the “Select Procedure” section, there is now an option called “Force SLC Mode“, which we should check. But let’s take it easy because we haven’t finished the modifications yet. There’s no point in trying to write this new firmware to the SSD if it’s still going to operate in its native mode, whether it’s TLC or QLC.

image 24

Now we’ve reached the crucial part that enables all these modifications we’ve made to become possible. We need to take the boot and firmware initialization files from a folder within MPTools and place these files in another directory of the program.

First, we return to the default directory of MPTools and open the “Firmware” folder within the software.

image 25

Inside this folder, we will find one named “2259,” which refers to the SM2259XT2 controller of this SSD. Within this folder, there should be another folder named “IMN48” along with a configuration file and parameters file.

image 27

Once again, we enter this IMN48 folder, where we will encounter numerous files and folders.

image 29

Let’s move forward and open the “00” folder, then select all the files and folders within the “00” folder.

image 31

We will “copy” (not cut) to the previous folder, the “00” folder, which should look like the following image:

image 33

And then we should enter the “XT2” folder and copy this single file inside it called “BootISP2259.bin” to this “00” directory as shown in the next image.

image 35

Next, we’ll copy all these files from the folder and paste them into the previous “2259” directory as shown in the following image:

image 39

IT IS IMPORTANT TO NOTE THAT THIS PROCEDURE WITH THESE FILES IS FOR THIS KIT OF SM2259XT2 + NANDS N48R.

OTHER SSDS WITH DIFFERENT NANDS FOLLOW THE SAME PROCEDURE, BUT WITH DIFFERENT FOLDER NAMES. THE N48 FOLDERS WILL BE NAMED ACCORDING TO THE NAND MANUFACTURER, AS SHOWN IN THE EXAMPLE BELOW OF AN SSD WITH SM2259XT2 CONTROLLER + KIOXIA BiCS5 NANDs.

P.S.: Some NAND models may not be 100% compatible. So far, I’ve only tested with Intel and Micron NANDs.

04 1

Tendo deixado isto claro, agora sim voltamos ao programa MPTools, vamos em Parameter novamente e vamos checar todas as configurações anteriores para ver se ainda estão aplicadas.

image 37

If everything is correct, let’s go to the “Test” section next to “Parameter,” which is the program’s main screen. Now we should put the SSD into ROM mode. Let’s close the software again.

HOW MUCH DID THE ENDURANCE INCREASED?

To calculate durability precisely, we need the following information:

Write Amplification Factor

NAND: Program/Erase Cycle

SSD’s Capacity

With these 3 parameters, we can have a basic understanding of TBW (Terabytes Written), but remember that it’s an approximate value. For a more precise calculation, following the JEDEC JESD218A parameters would be necessary, which includes more complicated parameters like Wear-Leveling Efficiency (W.L.E.).

Using this basic calculation with the SSD in its default mode, we see that it has a TBW of 120TB, with a Program/Erase Cycle of these Media Grade N48R NANDs around 900 P.E.C. And how do I know this? I managed to access the datasheet of the NANDs. Taking this into consideration, we can reach the conclusion below, considering the calculation:

image 41

120 TB (TBW) = (900 P.E.C. x 0.5 TB)
———————-
X (W.A.F)

X = 3.75 W.A.F.

We see that based on this, the SSD’s WAF in its native form would be quite high, in the range of 3.75, when tested in practical scenarios it was close to 3.8 WAF.

Now, in pSLC mode, the parameters change. The NAND from this Die can withstand up to 60,000 P/E cycles according to the datasheet, and its capacity drops to 0.12TB (120GB). When I randomly tested the SSD, I noticed that its WAF was below 2, which improved significantly.

X TB (TBW) = (60.000 P.E.C. x 0.12 TB)
———————-
1.8 (W.A.F)

X = 4000 TB (TBW)

We see that the TBW has increased drastically, from 120TB(500GB QLC) to 4,000TB (120GB pSLC), which is an increase of over 3333%, more than 3000 percent.

TEST BENCH
– OS: Windows 11 Pro 64-bit (Build: 23H2)
– CPU: Intel Core i7 13700K (5.7GHz all core) (E-cores e Hyper-threading desabled)
– RAM: 2 × 16 GB DDR4-3200MHz CL-16 Netac (c/ XMP)
– Motherboard: MSI Z790-P PRO WIFI D4 (Bios Ver.: 7E06v18)
– GPU: RTX 4060 Galax 1-Click OC (Drivers: 537.xx)
– (OS Drive): SSD Solidigm P44 Pro 2TB (Firmware: 001C)
– DUT SSD: SSD BX500 “SLC-Test” 2TB (Firmware: My custom firmware)
– Chipset Driver Intel Z790: 10.1.19376.8374.
– Windows: Indexing disabled to avoid affecting test results.
– Windows: Windows updates disabled to avoid affecting test results
– Windows: Most Windows applications disabled from running in the background.
– Boot Windows: Clean Image with only Drivers
– Test pSLC Cache: The SSD is cooled by fans to prevent thermal throttling, ensuring it doesn’t interfere with the test results.
– Windows: Antivirus disabled to minimize variation in each round.
– DUT SSDs: Used as a secondary drive, with 0% of space being utilized, and other tests conducted with 50% of space utilized to represent a realistic scenario.
– Quarch PPM QTL1999 – Power consumption test: conducted with three parameters—idle, where the drive is left as a secondary, and after a period of idle, a one-hour write test is performed, and the average power consumption is recorded

CONTRIBUTIONS TO PROJECT LIKE THIS IN THE FUTURE

If you enjoyed this article and would like to see more articles like this, I’ll be leaving a link below where you can contribute directly. In the future, I plan to bring a comparison showing the difference in SLC cache sizes, transforming a QLC or TLC SSD into SLC, among many other topics.

Paypal – [email protected]

CRYSTALDISKMARK

We conducted synthetic sequential and random tests with the following configurations:

Sequential: 2x 1 GiB (Blocks 1 MiB) 8 Queues 1 Thread

Random: 2x 1 GiB (Blocks 4 KiB) 1 Queue 1/2/4/8/16 Threads

image001 1image003 1

In these sequential scenarios, the difference is basically nonexistent because even with the pSLC Cache, the SSD already reaches its maximum bandwidth and the manufacturer’s sequential speeds. Not to mention that this is a quick test; in a more extensive and heavy benchmark, we will see that there will indeed be a difference.

image005 1image007 1

In terms of latency, there was indeed a considerable drop because when the SSD is in Idle, its NANDs, when they start to write or “read,” are in native mode, which would be QLC, and until they are reprogrammed to SLC, they have a certain latency. However, with the SSD in full pSLC mode, this latency is much lower because it always stays in pSLC mode.

image009 1image011 1

The same happens with its random speeds; we can see that there was a greater difference in these benchmarks compared to sequential speed, where the difference was almost negligible.

image013 1image015 1

The same happens at QD1; we can see that in reading, the SSD had an increase of over 16% in its speeds, while in writing, there was a much larger increase of over 30%.

ATTO Disk Benchmark QD1 and QD4

We conducted a test using ATTO to observe the speed of SSDs at various block sizes. In this benchmark, it was configured as follows:

Block sizes: from 512 Bytes to 8 MiB

File size: 256MB

Queue Depth: 1 and 4.

image017 2image019 2

The ATTO Disk Benchmark is a software that performs a sequential speed test with compressed files. Therefore, for a simulation under a data transfer load like in Windows, we typically see block sizes ranging from 128KB to 1MB. Now, we observe that the SSD in pSLC mode outperforms the SSD in its factory mode across all block sizes, which is impressive once again.

image021 1image023 1

The same pattern repeated at queue depth 1, although the difference in some block sizes was slightly lower compared to a queue depth of 4.

3DMark – Storage Benchmark

In this benchmark, various storage-related tests are conducted, including game loading tests for games like Call of Duty Black Ops 4, Overwatch, recording and streaming with OBS of a gameplay at 1080p 60 FPS, game installations, and file transfers of game folders.

image027 1
image029 1image031 1

In this benchmark focusing more on casual environments, we can see that even here, in a scenario fully representative of reality, there is indeed a performance difference, especially in latency. Although it may not be something entirely noticeable in everyday use in these “lighter” scenarios.

PCMARK 10 – FULL SYSTEM DRIVE BENCHMARK

In this test, the Storage Test tool was used along with the “Full System Drive Benchmark,” which performs light and heavy evaluations on the SSD.

pcmark10 fb og


Among these traces, we can observe tests such as:

  • Boot Windows 10
  • Adobe After Effects: Launching the application until it’s ready for use
  • Adobe Illustrator: Launching the application until it’s ready for use
  • Adobe Premiere Pro: Launching the application until it’s ready for use
  • Adobe Lightroom: Launching the application until it’s ready for use
  • Adobe Photoshop: Launching the application until it’s ready for use
  • Battlefield V: Loading time until the start menu
  • Call of Duty Black Ops 4: Loading time until the start menu
  • Overwatch: Loading time until the start menu
  • Using Adobe After Effects
  • Using Microsoft Excel
  • Using Adobe Illustrator
  • Using Adobe InDesign
  • Using Microsoft PowerPoint
  • Using Adobe Photoshop (Intensive use)
  • Using Adobe Photoshop (Lighter use)
  • Copying 4 ISO files, totaling 20GB, to a secondary disk (Write test)
  • Performing the ISO file copy (Read-write test)
  • Copying the ISO file to a secondary disk (Read)
  • Copying 339 JPEG files (Photos) to the tested disk (Write)
  • Creating copies of these JPEG files (Read-write)
  • Copying 339 JPEG files (Photos) to another disk (Read)
image034 1

In this scenario, which is a practical benchmark with a slightly greater focus on writing than 3DMark, as it is more productivity-oriented, it’s possible to notice the practical difference in day-to-day use. The difference was striking, almost twice the performance.

Adobe Premiere Pro 2021

Next, we used Adobe Premiere to measure the average time it takes to open a project of about 16.5GB with 4K resolution, 120Mbps bitrate, and full of effects until it was ready for editing. It’s worth noting that the tested SSD is always used as a secondary drive without the operating system installed, as this could affect the results, leading to inconsistencies.

image037 1

Here we can see that, as it is more of a scenario of sequential data reading from the project, the difference was almost negligible, just a variation between runs.

WINDOWS BOOT TIME AND GAME LOADING TIME

We compared the SSD with pSLC Cache and in pSLC Mode using the Final Fantasy XIV benchmark.

image038

The same happens with game loading times because the limitation lies in the game’s API, which differs from DirectStorage. This API is not optimized for us to feel a significant difference.

image042

The same can be said for Windows, as although it is a completely new system, it cannot take advantage of features like the one we applied to the SSD.

SLC CACHING

A large part of SSDs on the market currently utilize SLC Caching technology, where a certain percentage of their storage capacity, whether it’s MLC (2 bits per cell), TLC (3 bits per cell), or QLC (4 bits per cell), is used to store only 1 bit per cell. In this case, it’s used as a write and read buffer, where the controller starts writing, and when the buffer is depleted, it writes to the native NAND Flash (MLC/TLC/QLC).

image 40
image043

Through IOmeter, we can get an idea of the SLC cache volume of this SSD, as manufacturers often do not provide this information. Based on the tests we conducted, it was found that it has a pSLC cache volume that appears to be dynamic, relatively small, around 45GB. It managed to maintain an average speed of approximately 493MB/s until the end of the buffer, which is a good speed considering it is a SATA SSD.

However, after writing 45GB, it begins to enter the folding process because it allocated all its capacity to work as pSLC. So now we see the true Achilles’ heel of QLC SSDs. Its sustained speed was quite low, averaging around 50 MB/s.

image045

Now, when we transform this SSD into pSLC, we see that it writes to its full capacity of 120GB at an average of 498 MB/s. And to confirm, we wrote up to 500GB to the SSD, and even then, it continued rewriting its capacity more than 4 times at almost 500 MB/s.

image047

As we can see in the graph above, we averaged the SSD’s write speed, combining the speed within the pSLC Cache + Folding + Native. Taking this into account, we see that the difference was striking, almost 10 times higher.

FILE COPY TEST

In this test, the ISO files and CSGO were copied from a RAM Disk to the SSD to see how it performs. The Windows 10 21H1 ISO of 6.25GB (1 file) and the CSGO installation folder of 25.2GB were used.

image049

In a more realistic test like this, we can see that there is no difference because the SLC cache volume of the SSD natively is larger than the size of the tested file.

image051

And even when using a larger folder, it is still smaller than the volume of the SSD’s SLC cache. I don’t test with larger files because I use a RAM Disk, and since I only have “32GB” to make a larger RAM Disk, I would need more RAM.

TEMPERATURE TEST

In this part of the analysis, we will observe the temperature of the SSD during a stress test, where the SSD receives files continuously, to determine if there was any thermal throttling with its internal components that could cause a bottleneck or loss of performance.

image053

The SSD doesn’t even heat up because it’s a low-power consumption SSD, as we’ll see throughout the analysis, and I believe this sensor to be the NAND Flash sensor.

POWER CONSUMPTION AND EFFICIENCY

SSDs, like many other components in our system, have a certain power consumption. The most efficient ones can perform tasks quickly with relatively low power consumption, allowing them to transition back to idle power states where they consume less energy.

quarch programmable power moduleSPECIAL THANKS FOR QUARCH FOR SENDING THIS UNIT

In this section of the analysis, we will use the Quarch Programmable Power Module provided by Quarch Solutions (pictured above) to conduct tests and determine how efficient the SSD is. This methodology involves conducting three tests: measuring the maximum power consumption of the SSD, calculating an average power consumption in practical and casual scenarios, and measuring power consumption during idle periods.

This set of tests, especially those related to efficiency and idle power consumption, is important for users who intend to use SSDs in laptops. SSDs spend the vast majority of their time in low-power states (idle), so understanding their power consumption characteristics can significantly impact battery life and overall energy efficiency.

image061

We can see that thanks to this modification, its efficiency has increased dramatically. This occurred because, although the difference in power consumption was not as significant as we will see shortly, the speed in MB/s was extremely high.

Due to the benchmark exceeding the SSD’s 45GB cache by a large margin, it spent a significant portion of the test at a very low speed of less than 55 MB/s, resulting in low efficiency. In pSLC mode, it was able to write twice its capacity at even lower power consumption than in QLC mode, and its bandwidth did not drop at any point. This led to the significant difference in power consumption.

image055

Although this SSD naturally has low power consumption, we do observe a decrease when transforming it into pSLC mode. This occurs because SLC NANDs have only 2 logical levels, meaning the threshold voltage required to allow electrons to flow in the gate channel of each cell is lower since there are fewer levels needed to represent binary 1 or 0. In contrast, QLC NANDs have 16 logical levels, requiring a higher threshold voltage. This explains the reduction in power consumption.

image057

Once again, we see this in the average of both SSDs.

image059

Last but not least, the Idle test, which represents the scenario where the vast majority of SSDs are in everyday use. Here we can see that it had even lower consumption in Idle. Another positive point.

What can we conclude from this?

Once again, I stress the importance of caution with this procedure as it can indeed go wrong if not done correctly. However, we see that the differences are significant in some scenarios while more subtle in others. But now, in terms of durability, the difference is immense!

AI Books4 Dataset for training LLMs further

old.reddit.com - Comments

What?

  • More than 400,000 fiction and non-fiction book full-texts. Multiple languages, curated, deduplicated.

  • More than 6,000,000 scholarly publications, magazines, and manuals full-texts. Multiple languages, curated, deduplicated.

  • 150,000,000 metadata records

Format

Zstd compressed file, JSON lines, one per book/publication.

  • abstract, content - description and content in markdown format

  • issued_at - time of issuing of the object (not of the record itself)

  • metadata - ISBNs, publishers, series etc

  • id - identifier in external systems, if applicable (i.e. DOI)

other fields should be self-descriptive

Download:

magnet:?xt=urn:btih:a904e660355c49006b2e7d43893d31bf3c2be9cc&dn=libstc2.jsonl.zst&tr=udp://tracker.opentrackr.org:1337/announce&tr=https://tracker1.ctix.cn:443/announce&tr=udp://open.demonii.com:1337/announce

Show HN: Interactive Graph by LLM (GPT-4o)

columns.ai - Comments

"No Mow May" Won't Fix Our Biodiversity Problems

www.motherjones.com - Comments

A machine mowing grass

Pexels

This story was originally published by Undark and is reproduced here as part of the Climate Desk collaboration.

In 2020, the Wisconsin city of Appleton brought No Mow May to the United States. Each spring, by temporarily forgoing mowing and letting residential lawns grow with flowers, residents could support bees and other insect pollinators, proponents claimed. Indeed, they even said the practice was backed by their own published scientific study.

But a little more than two years later, critics turned up severe flaws in the work conducted in Appleton, and the study was formally retracted.

To Sara Stricker, a plant pathologist, it was another sign of anti-grass zealotry gone awry. In spring 2023, she launched a campaign criticizing No Mow May, saying the movement was misguided and delivered little on its intended value. But, she said, people don’t typically want to digest the science behind such a thing: “They just want the quick hashtag and a little sign with a cute little icon in it that makes them feel good.”

“It almost goes without needing evidence to say that a lawn has lower biodiversity than a native ecosystem.”

Before long, Stricker’s inbox filled with hate mail. For instance, she said she was accused of being in the pocket of industry. Stricker works as a communications and outreach coordinator for the Guelph Turfgrass Institute, outside of Toronto, which has outdoor research fields for the express purposes of studying the green stuff that covers lawns and sports fields and golf fairways. She maintains that she was just trying to start a conversation and acknowledges that her institution draws support from chemical manufactures and the lawn care industry—which is not uncommon in agricultural and horticultural research. But, she said, “None of us are walking around with devil horns saying, ‘Woohaha, I want to kill something today.’ We’re all in it because we like being outside, we like doing sports, we like nature.”

Stricker had not exactly called for a Blitzkrieg on biodiversity. In fact, she encouraged people to plant a wider range of species if they wanted to help support wildlife. (Other experts have proposed similar measures.) In an experiment described in GreenMaster, a trade publication for Canadian golf course managers, her institute found that No Mow May was unlikely to make much of a difference: Over the course of the one-month study, unmowed plots of Kentucky bluegrass did not substantially support more flowers compared to plots mowed at two-and-a-half inches.

But why had experts on grass, at a premier grass-growing institute in North America, come out swinging against something as seemingly innocuous as No Mow May? If something as simple as not mowing for a month doesn’t do much for biodiversity, then what lawn-care practices—from tearing up sod entirely to planting lush wildflower meadows—are supported by data and research?

Lawns represent one of the largest, fastest growing landscapes in the US. These ecosystems—water-hungry, energy-intensive monocultures—extend far beyond the picket fence, including highway medians, cul-de-sacs, and corporate office parks. De facto lawns also exist under solar arrays, on soccer fields, and in city parks. In the US, it’s a landmass that, by some estimates, covers an area about the size of Iowa.

The concept of well-manicured, tightly shorn spaces originated as a status symbol in Europe. Colonizers introduced grasses in an effort to replicate the places they left. By the 18th century, wealthy Americans began tending formal lawns, and much later, particularly in the wake of post-war industrialization and suburban development, the masses followed suit.

But by the 1980s, the lawn began to lose its luster as nonprofit organizations and individuals increasingly called for its eradication. In 1989, the writer Michael Pollan published a landmark essay “Why Mow?” which indelibly described lawns as “nature purged of sex and death.” In some circles, lawns have come to exemplify a consumptive sensibility. “Over the past 50 years, we’ve slowly fallen out of love with lawns,” The Washington Post reported in 2022. “They began to signal waste, disregard, disharmony, homogeneity, gentrification, zombie Boomerism.”

“You can drive a stake through its heart, you can put on the garlic,” but you still won’t ever get rid of the grass.

The imperatives to remove lawns span a range of concerns: managing scarce water, building climate resiliency, boosting biodiversity, and even supporting mental health. As J. Leighton Reid, a restoration ecologist at Virginia Tech, put it, any change is probably better than the status quo. “It almost goes without needing evidence to say that a lawn has lower biodiversity than a native ecosystem,” he said. “I mean, that’s just inevitably going to be the case.”

But what actually works? Quick-fix lawn-conversion solutions encounter several problems in practice. For one, contemporary agricultural and horticultural research often focuses on commercial production on a large scale. (Private firms, such as those marketing chemical fertilizers and herbicides, overwhelmingly bankroll R&D in the US.) In contrast, ornamental lawn maintenance falls to practitioners—DIYers and hired professionals alike—who learn from experience and tend to focus on what looks best. Advocates also take matters into their own hands, although no single foolproof method for replacing the lawn and transforming it into a more functional ecosystem exists.

Perhaps the most obvious and most enduring problem rests with grass itself. Grasses generally have a number of reproductive methods and survival mechanisms that make them hard to wipe out. As Laura Jackson, director of the University of Northern Iowa’s Tallgrass Prairie Center, which conducts large-scale prairie restoration, put it: “You can drive a stake through its heart, you can put on the garlic, you can get out the silver cross or whatever, and you’re still going to have that stuff.”

Old habits die hard, too. When it comes to lawns—to walk barefoot on a soft carpet of grass, the sensibility, the institution of lawn care, the whole way of thinking—the practice seems indestructible. And so, some people fire up gas-powered mowers while their neighbors stake No Mow May signs in their lawns gone “wild.” Surely, there has to be a middle ground.

In ecological circles, there is a consensus for why the traditional lawn is perhaps long overdue for disruption, as monoculture grasses do not support much life. Simply put, lawns are deceptively lush: They look green, but are not figuratively “green” in terms of supporting a functional ecosystem.

One study on 159 residential yards in the Washington, DC, area found that, even in the leafy suburbs, an area rich with flowering plants, the landscape filled with nonnative vegetation lacked resources for birds. These nonnative plant species supported fewer insects regularly eaten by one beloved native bird species, the Carolina chickadee. In essence, the suburban landscape doubled as a food desert for the birds.

Hence, the impetus to convert. The best way to do so, however, is unclear. Looking at grasslands in Virginia, for instance, one master’s thesis study suggests that native wildflowers established more consistently when herbicide killed the existing grass completely (rather than seeding the wildflowers with no grass removal). Another PhD student found evidence that the resulting level of native plant diversity in restored grasslands represents a pale facsimile compared to grassland that remained relatively undisturbed.

“You can’t take that human piece out of restoration as much as you may try. You can’t pretend it’s just for nature.”

Reid, the Virginia Tech restoration ecologist who oversaw these studies, said he’s not sure how well the results translate since the studies focused on large-scale post-agricultural production systems. But one takeaway, given that native species fare better with less competition from grasses, is that it’s a case for clearly delineated strips that spatially separate grass from native plantings.

So, it’s not that there is disagreement over the why. Lawns could stand to benefit from greater biodiversity. But it’s the how that should happen—from grass-smothering mulches to sod-busting mechanical tools to chemical herbicides.

The lack of one-size-fits-all prescriptive advice isn’t just a matter of the heterogeneity of the landscape—the average rainfall and climate in Virginia is not the same as, say, southern California—but also of favoritism on an institutional scale. Financial incentives focus on research related to the commercial production of food; Reid, meanwhile says there should be no less imperative to study lawn conversion with an eye towards biodiversity.

That’s unlikely, though. His research, in part, grew out of an effort to create pastures that helped prevent cows from getting sick from eating nonnative grasses in the summer. “If we pitched that as a lawn transformation study,” he said, “I don’t think they would have received it as well as pitching it as a cattle production study.”

Out in the Corn Belt, Jackson, at the Tallgrass Prairie Center, which provides seeds and technical assistance for plantings along public roadsides in Iowa, contends that urban lawns probably amount to a rounding error in terms of, say, providing sustenance for migratory butterflies. “It’s absolutely of no significance whatsoever from the point of view of monarch populations,” she said. “From a political point of view, from the point of view of people caring about monarchs, if that were to translate into political action, that’d be great, that would be significant. But from the point of view of water quality or number of stems of milkweed, it doesn’t move a needle at all.”

Still, the institute’s research has some potentially useful findings. Jackson’s research on seeding milkweed (the host plant for monarch caterpillars) in road ditches with existing vegetation showed abysmal results without applying herbicides, such as Roundup, prior to planting. “You get precisely no plants,” Jackson said. “You use Roundup once, you get a few more, and, if you round it up a couple of times, you get a few more.”

While Jackson added that she personally prefers not to use chemical controls—which are mired in controversy because of their deleterious effects on soil, insect, and human health—the amounts of herbicides used annually in wildflower restoration amount to little when compared against the high volumes sprayed on crops like corn and soybeans. The reality is there’s little prairie left, and it isn’t regenerating on its own. “We’ve done a lot of damage and it’s not going to be easy to undo that damage,” she said.

“I don’t hate lawns. I like functional lawns. And sod lawns are not functional.”

Jackson championed restoration, and her blanket advice for others was simply to underscore the uncertainty: “A great deal of humility is called for in this business.”

Meanwhile, Linda Chalker-Scott, a professor and extension urban horticulturist at Washington State University, suggested grass-killing herbicides only be used as a last resort. Chalker-Scott has something of a reputation for debunking “horticultural myths.” Her initial skepticism piqued when she was reading a textbook on landscaping and came across some fishy citations: “So that’s when I started thinking, ‘Well, where is this information coming from?’ And then tracing it back and saying, ‘Well, this isn’t science. This is just someone’s anecdotal experience or some guru, self-proclaimed expert telling people what to do.’”

She generally cautions against digging up grass (it removes organic matter and disturbs the soil), and has co-authored one study that found flaws with covering a yard with cardboard and other sheet mulches in order to smother and kill off existing vegetation. In terms of reducing the movement of gasses from the soil into the atmosphere and vice versa, she said that black plastic (which kills unwanted plants by solarization and is used by organic practitioners) is worse than using 12 inches of coarse wood chips. Mulching grasses when dormant, she said, “is the single best way to prepare soil for planting, to get rid of weeds, and to pretty much improve and retain soil tilth.”

Chalker-Scott also made it clear she wasn’t calling for the wholesale removal of lawns. “I don’t hate lawns. I like functional lawns. And sod lawns,” she said, describing those planted with a roll of turf, “are not functional.”

Perhaps there is no one true path carved out of the grass. About 10 years ago, Nancy Shackelford, an ecologist at the University of Victoria, co-authored a paper outlining nine principles for restoration. “We talked a lot in that 2013 paper about resilience and self-sustaining ecosystems, as in, like, ‘Take the humans out of it.’ And I don’t really aspire to that anymore.”

Today, she said, the best laid plans involve restored ecosystems that people want to maintain. “Restoration is always about values. Always,” she said. “So, you can’t take that human piece out of restoration as much as you may try. You can’t pretend it’s just for nature.”

Ecology fundamentally lacks grand unifying theories, and her view reflects a larger shift. When the main restoration group, the Society for Ecological Restoration, updated its primer, for instance, the international conservation organization described restoration taking many shapes. Any step seemed like a good first step, Shackelford said, and, even what might appear like mere symbolic restoration of lawns can be beneficial. Still, she said, the international community sometimes implied that a restored ecosystem could and should take care of itself.

But she was less and less sure: “I actually think humans have a role to play in taking care of all ecosystems. It’s kind of our job at this point.”

More Mother Jones reporting on Climate Desk

LET’S TALK ABOUT OPTIMISM FOR A CHANGE

Democracy and journalism are in crisis mode—and have been for a while. So how about doing something different?

Mother Jones did. We just merged with the Center for Investigative Reporting, bringing the radio show Reveal, the documentary film team CIR Studios, and Mother Jones together as one bigger, bolder investigative journalism nonprofit.

And this is the first time we’re asking you to support the new organization we’re building. In “Less Dreading, More Doing,” we lay it all out for you: why we merged, how we’re stronger together, why we’re optimistic about the work ahead, and why we need to raise the First $500,000 in online donations by June 22.

It won’t be easy. There are many exciting new things to share with you, but spoiler: Wiggle room in our budget is not among them. We can’t afford missing these goals. We need this to be a big one. Falling flat would be utterly devastating right now.

A First $500,000 donation of $500, $50, or $5 would mean the world to us—a signal that you believe in the power of independent investigative reporting like we do. And whether you can pitch in or not, we have a free Strengthen Journalism sticker for you so you can help us spread the word and make the most of this huge moment.

Donate payment methods

LET’S TALK ABOUT OPTIMISM FOR A CHANGE

Democracy and journalism are in crisis mode—and have been for a while. So how about doing something different?

Mother Jones did. We just merged with the Center for Investigative Reporting, bringing the radio show Reveal, the documentary film team CIR Studios, and Mother Jones together as one bigger, bolder investigative journalism nonprofit.

And this is the first time we’re asking you to support the new organization we’re building. In “Less Dreading, More Doing,” we lay it all out for you: why we merged, how we’re stronger together, why we’re optimistic about the work ahead, and why we need to raise the First $500,000 in online donations by June 22.

It won’t be easy. There are many exciting new things to share with you, but spoiler: Wiggle room in our budget is not among them. We can’t afford missing these goals. We need this to be a big one. Falling flat would be utterly devastating right now.

A First $500,000 donation of $500, $50, or $5 would mean the world to us—a signal that you believe in the power of independent investigative reporting like we do. And whether you can pitch in or not, we have a free Strengthen Journalism sticker for you so you can help us spread the word and make the most of this huge moment.

Donate payment methodsMore about:Climate ChangeClimate DeskScience

Emerge Tools (YC W21) is hiring senior engineers to automate dead code deletion

www.emergetools.com - Comments

About us

Emerge is a suite of developer tools designed to supercharge mobile apps and the teams that build them. Emerge was founded in December 2020 by Noah Martinand Josh Cohenzadehafter realizing many mobile companies were each building custom solutions to solve the same problems.

Our team

Our team is small (just 6), technically experienced, and tight-knit. We're fully remote spanning from San Diego, Seattle, Boston, Uruguay and New York. We still love to spend time in person together, so we try to have a company retreat in cool places a few times a year.

Will Better Superconductors Transform the World?

www.quantamagazine.org - Comments

If superconductors — materials that conduct electricity without any resistance — worked at temperatures and pressures close to what we would consider normal, they would be world-changing. They could dramatically amplify power grids, levitate high-speed trains and enable more affordable medical technologies. For more than a century, physicists have tinkered with different compounds and environmental conditions in pursuit of this elusive property, but while success has sometimes been claimed, the reports were always debunked or withdrawn. What makes this challenge so tricky?

In this episode, Siddharth Shanker Saxena, a condensed-matter physicist at the University of Cambridge, gives co-host Janna Levin the details about why high-temperature superconductors remain so stubbornly out of reach..

Listen on Apple PodcastsSpotifyTuneIn or your favorite podcasting app, or you can stream it from Quanta.

Transcript

[Theme plays]

JANNA LEVIN: On April 8th, 1911, a Dutch scientist made a chilling discovery. Using a carefully engineered instrument filled with liquid helium, physicist Heike Kamerlingh Onnes delicately lowered the temperature of mercury closer and closer to absolute zero. Suddenly, at an unimaginably cold negative 452 Fahrenheit, the supercooled mercury conducted electricity with perfect efficiency and no energy loss to heat. It was the first superconductor.

I’m Janna Levin, and this is “The Joy of Why,” a podcast from Quanta Magazine, where I take turns with my co-host, Steve Strogatz, exploring the biggest questions in math and science today.

The discovery of superconductivity would win Kamerlingh Onnes the 1913 Nobel Prize in Physics.

[Theme ends]

But more importantly, it marked the start of an unresolved quest for material that maintains perfect conductivity at room temperature. A quest that’s recently seen many claims put forward and then retracted. Today, we ask physicist Siddharth Shanker Saxena, known to his friends as Montu: What makes room-temperature superconductivity so elusive and how might its discovery reshape society?

Montu is a principal research associate in the Cavendish Laboratory at the University of Cambridge, researching superconductors, magnets, graphite and renewable energy applications. He also teaches at Cambridge’s Center for Development Studies, and chairs the Cambridge Central Asia Forum. Welcome to the show, Montu.

SIDDHARTH SHANKER SAXENA: Thank you, Janna. Excellent intro.

LEVIN: Thank you.

SAXENA: And I think a very fitting thing to say: “chilling discovery.”

LEVIN: Yes, our script writers like puns. Before we get into the absolutely amazing and unforeseen phenomena of superconductivity, I want to talk about regular conductivity. We have fundamental elements just on our periodic table, things that are made in the universe, that are conductors, and we call them metals. Can you tell us just very briefly the basics of conductivity?

SAXENA: Sure. So there are different ways of understanding conductivity. Conductivity of water, conductivity of heat, conductivity of electricity. And these properties of elements, it’s one side commonplace, and another side extremely mystical.

Like, when you walk into a room, you flick a switch, and something happens. We can say a circuit is completed. The current starts to flow. It can only flow in a conductor. It’s a conduit through which things can flow. And if it’s not, it stops flow, it’s an insulator.

So you flick that switch, and you allow the electrons to flow all the way to your light bulb, your computer, your fan, or whatever else that is, and it starts to work. And that is conductivity and the material property needed for that to happen is metallicity. Something has to be metallic for it to have basic conducting properties. Of course, there are various caveats and that hopefully we’ll chat about as we go forward.

LEVIN: Yeah, so basically these elements in the periodic table are all lined up on one side because they allow their electrons to do what you’re describing. To run freely through the material, carrying energy with them. And insulators hang on to their electrons and don’t allow it to happen. I use a cloth to hold my kitchen pan…

SAXENA: Yes.

LEVIN: But the pan itself, I rely on allowing the conductivity. Now, how is superconductivity so much different from this naturally occurring phenomenon?

SAXENA: First of all, we often think electrons can freely move in a conductor, but they don’t really move freely. That is the reason why you have your electricity bill. When electrons travel through the metal, they fight their way through other electrons and other defects and so on, and lose energy as they move forward. And that loss is what we pay for. And the process that is functionalized when this is happening is limited by the amount of power or current or number of electrons we put into the conduit.

While superconductivity is literally the superpower of those electrons. They can travel this time freely without being inhibited by other electrons or defects and so on. So once you get the ball rolling, they continue to go until the system cannot sustain that property.

LEVIN: It’s quite amazing, because as you say, energy is money. And so it costs energy every time you waste some of your electricity into heating up your charger, or your phone gets hot, or your computer needs to cool off. That’s all loss. And superconductivity doesn’t have these losses. That’s quite miraculous. Now, what are some examples of superconductors that are actually in application now?

SAXENA: I think the most prominent one that affects our daily — hopefully not our daily lives, but we encounter it  — is a CAT scan or MRI scanner. That’s made of a superconducting coil, which is used to generate magnetic fields. And it’s a primary well-being tool that we have.

Perhaps a more fantastic one is the new era of transport. The maglev trains, for example. Levitating trains that go at speeds similar to aircraft.

There are multiple other smaller aspects. Superconductors allow for us to develop very sensitive devices, which can pick up signals which are minute, which would otherwise not be possible to pick up. And they can be applied from anywhere, in IT or healthcare or mining applications or various other things like that.

LEVIN: Now, why can’t I have these fantastic gadgets in my home and save on my energy bills?

SAXENA: That’s literally a million-dollar question, or multimillion-dollar question.

[Both laugh]

SAXENA: And two interesting aspects of this. One is the fact that superconductivity itself, as you started by telling us in the very beginning of the podcast, was when that liquid-filled special device used by Kamerlingh Onnes was used to cool down mercury.

And similarly, we have to cool down most of these metals to a superconducting state. So basically you start with a normal metal, where electrons are fighting thermal barriers, but then you take it through a transition at which it starts to work in the super way. So now, for us to have that property, we need that special device to keep superconductivity maintained at those temperatures. And that’s what has inhibited its general use.

And that is in itself a very interesting problem that, as human beings, we have conquered the heat. We sit in a car, we turn the switch on, we put a newborn baby a foot away from thousands of degrees of heat and not even think about it. At the same time, we don’t have the same kind of control yet over cooling. Superconductivity happens at lower temperatures. However, our ways of cooling still need developing.

LEVIN: Right. So now, after Kamerlingh Onnes’ initial discovery of mercury’s superconductive properties, where did the research go? Did it immediately go to “let’s try to do this at warmer temperatures”? Because, as you said, he had to supercool it to a staggeringly cold temperature to observe this phenomenon.

SAXENA: So, if you look at the history of the development of superconductivity, we’ll find two approaches. And that happens with most physical phenomena which is discovered. The instinct of a physicist, or chemist or basic scientist, is to understand why is it happening at all? Just imagine it was happening in that era when it happened. This was the first time it’s ever been seen. One wasn’t thinking necessarily about using it or controlling it, just to understand what it is. Why is it happening at all? Or is it even true? Can we find other examples of it? Is it just a flaw in the measurement?

The early period went on establishing the phenomenon itself. Understanding its parameters. When it happens, where it happens, how it can happen. And then the next step: Can it happen in things other than mercury? And that’s when the juices start to flow. You start to think we have different materials in which this can happen. Can this happen in alloys? Can it happen in compounds? And as that happens, you start to talk to engineers, you start to talk to people in other fields, and their input is what make you realize that it can possibly be used for other things. And the two efforts started to go in parallel but separate ways: the application of superconductivity versus understanding of superconductivity.

And there’s another very interesting lever here which we haven’t mentioned. It’s not only temperature, it’s also pressure. In fact, room-temperature superconductivity is already discovered. It’s not something that’s elusive anymore, except that it happens at very high pressures. Mikhail Eremets and colleagues in 2015 already produced near-room temperature superconductivity. And now there are various examples of it.

LEVIN: Now let’s talk about why it happens, because it’s extremely different from the ordinary conductivity of the naturally occurring elements. You might imagine if I supercooled something that the electrons’ motions could be inhibited, and that actually conductivity would therefore drop to zero. And so this is really a very different and surprising phenomenon. Can you talk us through the Nobel Prize-winning work of John Bardeen, Leon Cooper and John Schrieffer and their theory of superconductivity?

SAXENA: That was a landmark moment, not just in understanding superconductivity, but understanding quantum phenomena altogether. So BCS theory: The basic essence of their theory is that they were able to explain that the electrons don’t travel alone like they do in a metal. They form a coherent state, what we call the Cooper pair. The two electrons come together and, if you want to use an analogy, they are the bully on the street. They’re able to push everyone else away so they can move effortlessly in this maze of other electrons and so on.

The formation of the Cooper pair was something that was only describable and conceptually tangible through the work of Bardeen, Cooper and Schrieffer in the 1950s. And, in fact, Cooper was the one who understands that when two electrons are able to come together in this way, they form a coherent state. It’s a lot of electrons which become coherent, but they can be described as a set of pairs, or a condensate that forms.

LEVIN: So fascinating because electrons, of course, if you’re in the quantum world or you’ve studied quantum theory, are notorious for not wanting to pair up.

SAXENA: Yep.

LEVIN: And the Pauli exclusion principle famously says that there’s, in fact, a quantum pressure associated with trying to jam electrons together. They don’t like it.

So this phenomenon that they discovered is extremely counterintuitive: the collaboration with the lattice of ions left behind when the electrons start to move away. When they pair up, now they have the opposite phenomenon where they want to bunch together. So you don’t just get one pair. You now have an encouraging accumulation of these electrons and hence this runaway phenomenon of superconductivity. It’s absolutely counterintuitive and fascinating. And that theory has held up well over the years?

SAXENA: Yeah. One picture that the theory builds in your mind, is that of a lattice and the vibrations of lattice, what we call phonons. And so you can think in terms of, if this boat or ship is moving in water and it creates a wake behind it, while it looks like it’s pushing the water back while moving forward, it creates that small wake where things can get trapped, which is attractive potential.

So it held up quite well for a vast majority of superconductors. And one of the important reasons for that is that the electron has the other property, the spin. And spin is what gives it magnetism. So everything we have discussed now is the charge of an electron. And so while we can talk of electron and its Pauli exclusion principle, we now turn to Bohr and spin, and talk about the spin itself and how opposite spin electrons can attract each other. And a Cooper pair has a spin-up/spin-down configuration in the BCS theory description.

LEVIN: Now why does it require — so far, hopefully not forever — this supercooling?

SAXENA: So, the main barrier that one has to overcome is the thermal one. So you can think about how the heat inhibits that coherence to form. It keeps rattling things before they can come into a coherent state. So we need to get to the temperature in which the electrons are interacting with the other electrons rather than other vibrations.

So two things. We have to have a cooperation between the electrons themselves, and the cooperation between those electrons and the lattice. And this lattice is driven by heat. And the lattice continues to be energetically unfavorable till you get to the temperature at which it starts to become cooperative. So we need the thermal side to decrease for the quantum state to form.

LEVIN: So that suggests that achieving room-temperature superconductivity is going to be hard. And as you said, we’ve seen it only under equally extreme conditions of high pressures. Do you think it’s hopeless, our attempts to achieve room-temperature superconductivity without the high pressures?

SAXENA: Can we hold a cube of ice over open flame and it doesn’t melt? When we talk about room-temperature superconductivity, that’s what we’re trying to achieve here in terms of an analogy. And so if that happens, usefulness aside, if can you hold ice cube over fire, it’s just shockingly amazing and mind-blowing.

On the other hand, there are ways in which we can protect the state because we know that when we chemically make compounds, when we change atoms, we change the internal pressure in a material. We increase or decrease the pressure between bonds, between elements, and that changes the properties. So by playing with the material, we are able to create the same conditions as a pressure does.

LEVIN: We’ll be right back.

[Break for ad insertion]

LEVIN: Welcome back to “The Joy of Why.”

So people have really been investigating synthetic materials as a way to make a big breakthrough. Now there have also been a number of very high-profile declarations of success, published in journals as prestigious as Nature, of new materials or synthetic materials that show room-temperature superconductivity. But then they were retracted. So what’s going on with these kind of controversial claims?

SAXENA: Yes, a couple of things to say about that. The first one, I want to reiterate that it’s not the room-temperature superconductivity which is in question. The claims are about ambient pressure or near-ambient pressure, not about room temperature at all. The question is, can it be achieved in ambient conditions?

So first of all, these high-pressure experiments are extremely difficult. I am a high-pressure scientist myself. So I know the difficulty and the challenge that comes with it. At the same time, it is the most productive in this area. And combined with the difficulty of experimental endeavor, and the promise it has for applicability, we feel that people have been rushing to give big answers. And the whole sociology of academic endeavor falling in sync with this very difficult to achieve but very promising area, has produced very interesting, and in many ways destructive, tendencies. I would say that the vast majority of superconductivity researchers are very careful.

There is a very fun word. We call them USOs. So, periodically, just like what happens with UFOs, all of a sudden, somebody declares there’s big news for a flash, and then it’s gone. Many journals have gone into the commercial publishing world rather than academic publishing. So it’s a nexus of several things which have led to these powerful claims.

But as a scientist, it just whets my appetite, rather than discourage. What I am worried about is that the public interest, and thus political interest, in this wonderful phenomenon — extremely unusual, extremely promising — could get damaged if we rely on those USOs.

LEVIN: So can you give us a little bit of intuition briefly about what these synthetic materials are, how they’re arranged out of what we consider to be ordinary atoms? Are they sheets of different fundamental elements? How are they constructed?

SAXENA: Sure. They’re like houses, they come in different shapes and sizes. And similar to houses, they have different who-can-live-in-it, and how comfortable they are. Superconductors actually come in all shapes and forms. So they can come as cubic material. So think of a structure of a rock salt, you can have that cubic material that can also be superconducting. Even gold, you can look at that.

But then you can have graphite, for instance, layers of carbon [inaudible], but also other materials, and they are very weakly bound together. So what makes graphite interesting for scientists, the reason we can write with pencil, is that those layers just fall apart. They just come onto the paper. We can write with it.

That means we can put other things in between, and that can change interactions between the sheets themselves and also between what we put inside those sheets. So these are so-called 2D materials. Before the advent of the recent room temperature, high-pressure superconductors, there was a whole family called high-TC superconductors. And these were mostly two-dimensional materials. And two-dimensionality, until today, has played a very important role in finding superconductivity.

The analogy that I gave you earlier: the boat is moving, and that there’s a small wake which can trap things in it. But if you imagine that all starts of wobble, i.e., 3D. You increase the dimensionality of your motion. Then it becomes less likely that things can get attracted and trapped and become coherent.

You can have another simpler analogy, that if you take a vat of treacle or honey and you throw a pebble in it, it’ll deform. But since it’s viscous, it cannot propagate. So it starts to retract and everything near it can get attracted and coherently bound. But if you take the same thing and start to wobble it in three dimensions, it’s less likely to happen.

So two-dimensionality has played a very important role. And we don’t know if this is true for these high-pressure phases yet. They look more to be 3D. One of the avenues of research, is can we achieve that kind of condition in 2D materials? And that’s where most likely we’re going to see zero pressure room temp superconductivity. It’s likely to come from lower dimensional materials.

LEVIN: A lot of the scientists that I most admire are unafraid of failure — their curiosity outweighs their fear of failure. You mentioned that you’re in this very challenging area of this high-pressure superconductivity. Give us a little glimpse into your process. What is a working day like in your laboratory?

SAXENA: So my high-pressure lab, it’s also a low-temperature lab. High pressures, because it’s the most difficult part of the process, it gets highlighted. In my lab, first thing that happens is making the material, or working with someone who makes the material. And identifying that a material is what it is.

See, this is where the drama is. Even the discussion that we just had about the previous cases, which were overblown, we don’t fully agree because we don’t know what the materials are. So in my lab, we spend most of our time, sometimes more than a year even, trying to hone down on the material is what it is. And that’s where the resilience of the researchers, the Ph.D. students and myself comes in. Because it could turn out that, after a year, this is not something we want to measure anymore. And we look for new systems all the time in which this thing can happen.

And then, we try to cut the sample down to size, literally. Because pressure requires a very small volume. So, a few tens of microns thickness, and a hundred-micron width, and so on, is where the highest pressures experiments happen. So then it comes down to attaching those famous electrodes to the samples, and then trying to put them in the pressure cells. And then you come to the cryostat and you chill it — literally the opposite of watching water boil. When you make a material chemically, it has certain set of atoms arranged in a particular way, and certain properties. So why pressure is a really important tool is that when you compress something uniformly — hydrostatically, in technical words — you change those atomic distances.

And so effectively at each pressure, you have a new material. And at each pressure point, you can then measure all those properties. The nice thing about this way of searching is that you can have very fine steps. You can increase the pressure, you can release the pressure, and you can keep searching for new and new states.

LEVIN: Would it be fair to say that you’re therefore, as you increase the pressure, looking at phase transitions?

SAXENA: We are looking at both. So we’re looking at change and uniform change in properties, and hoping for that very drastic change, and that will be the phase transition, yes.

LEVIN: If one of these USOs were to become a bona fide reproducible synthetic material that shows superconductivity at ordinary conventional conditions that you can find in someone’s apartment, this would doubtless be incredibly lucrative. And that’s because it’s going to have some very serious implications socially. Can you talk me through some of the societal ramifications of succeeding here?

SAXENA: It may sound biased coming from me, being a superconductivity researcher, but it’s obvious that the ramifications of superconductivity being available in ambient conditions are going to be transformative for all things around us. People keep talking about AI all the time. That’s nothing. Here we are talking about energy efficiencies, which are going to transform how we travel, how we communicate. We’re talking about data farms. We’re talking about power grids. We’re talking about ships, planes, everything. Just like all of those things have a conductor in it, it’ll have a superconductor in it.

LEVIN: Presumably, they’re not going to immediately be available freely across the globe. Presumably, there will be some countries that have faster access because of their investment?

SAXENA: That is absolutely correct. The infrastructure, both industrial and scientific, meaning laboratory and the manufacturing, certainly is available only in the global north. And there is obviously a great potential for it in some of the middle-income countries. But that still leaves a huge part of globe out, which cannot produce or sustain production of these kind of materials.

They tend to be in geographies of Eurasia, Australia and some other parts of the globe only. But I would say that it’s not only about where they occur. For example, South Korea, which has zero iron ore deposits, but is one of the biggest ship makers and steelmakers. So it’s more about how you’re plugged into a system, and supply and value chain. It’s not only about having natural resources. And then you have countries of central Asia having vast resources, but they don’t produce any of them in the way they can be used. So that it’s more than just having it. The discovery itself is not going to do it.

LEVIN: Right, we have to remind ourselves that we really are in this together. We have to get along to make the future work. You clearly believe that superconductivity is one day possible at more ordinary conditions. Do you think we’re close?

SAXENA: One way of talking about this: Does a UFO sighting mean that we’re close to finding other aliens? Is it a symptom of that or not? One can think in that way. But from within the field, our progress has been absolutely impressive in the last 20 years. And that has to do with our ability to make materials, and the kind of experiments we can do now using high pressure and high fields and other conditions. So the stage is now set better than ever before to be able to find these materials, or we have found these materials, so how to engineer these to be in ambient conditions.

LEVIN: Fascinating. Now, you have a background not only in physics but also anthropology and history. How do these other subjects inform your both scientific approach and your bigger picture?

SAXENA: I often describe myself as undisciplined because I’m not bound by any particular discipline. I’ve been lucky to have had the chance to study, interact and teach and work in all these areas. But fundamentally, what I’m looking at is the same thing.

For instance, if you have a bottle of water, if you hold that bottle in your hand, reflect for a second that the hand, the bottle and the water are all made of exactly the same elements. But these three things have nothing in common, absolutely nothing. Live, dead, transparent, translucent, liquid, solid, whatever you call it, there’s nothing in common. And this is where we come in, the modern-day scientists, to say: It’s not only about what things are made of. It’s a question of how things interact. And understanding the interaction gives rise to new properties. And they can be quite counterintuitive, but we must find probes to measure and understand those properties. But also find parameters to tune them, like pressure, field temperature and so on.

Human beings are like those particles. And just imagine the pressure-temperature axis in which a human being can survive. It’s extremely narrow. And yet, our interactions with each other and our interactions with the environment produce entirely different cultures, languages, ways of thinking, and science itself.

LEVIN: There’s a question we here at “The Joy of Why” like to ask our guests, and that is, what about your research brings you joy?

[Theme plays]

SAXENA: The discovery. And doing it with the team, with people, the colleagues. That moment of togetherness when we find something together. Discovering something alone is not something that I have found fun. I found that being part of a group who are working towards some aim, going through trials and tribulations, and then the discovery happens. And it’s a reward that’s shared, without having to slice it up.

LEVIN: No, it’s beautiful. At the end of the day, science is a human endeavor. We’ve been speaking with physicist Siddharth Shankar Saxena, that’s Montu to us, on superconductors and their potential to change the world. Thanks so much for joining us, Montu.

SAXENA: Thank you. It’s been a pleasure.

LEVIN: Pleasure to have you here.

“The Joy of Why” is a podcast from Quanta Magazine, an editorially independent publication supported by the Simons Foundation. Funding decisions by the Simons Foundation have no influence on the selection of topics, guests or other editorial decisions in this podcast or in Quanta Magazine.

“The Joy of Why” is produced by PRX Productions; the production team is Caitlin Faulds, Livia Brock, Genevieve Sponsler and Merritt Jacob. The executive producer of PRX Productions is Jocelyn Gonzales. Morgan Church and Edwin Ochoa provided additional assistance.

From Quanta Magazine, John Rennie and Thomas Lin provided editorial guidance, with support from Matt Carlstrom, Samuel Velasco, Nona Griffin, Arleen Santana and Madison Goldberg.

Our theme music is from APM Music. Julian Lin came up with the podcast name. The episode art is by Peter Greenwood and our logo is by Jaki King and Kristina Armitage. Special thanks to the Columbia Journalism School and Burt Odom-Reed at the Cornell Broadcast Studios

I’m your host, Janna Levin. If you have any questions or comments for us, please email us at [email protected]. Thanks for listening.

The Iberian lynx doubles its population in just three years

english.elpais.com - Comments

LinceA litter of Iberian lynxes from Ciudad Real.Alexandra Surkova-WWF

The Iberian lynx (Lynx pardinus) continues along its upward path, although it is still at risk of extinction. The last census in 2023 shows that the species has doubled its population in the last three years and has reached 2,021 individuals, with 1,299 adults or subadults and 722 cubs. Despite the good data, 750 breeding females would be needed to classify the species in a favorable conservation status, and in this latest count only 406 have been detected. According to Spain’s Ministry for the Ecological Transition, they are “gradually” getting closer to the necessary number, but are still falling short.

Captive breeding centers have played an essential role in this recovery. From 2011 to 2023, 372 lynxes born in the four existing centers have been released. The population has been expanding, and last year the reproduction of the species was verified in 14 population centers, in addition to the stable presence in new areas of the Spanish region of Murcia, and the provinces of Albacete, Badajoz, Toledo and Ciudad Real. Most of the specimens, 1,731 or 85% of the total, live in Spain and the rest, 291, are in Portugal. The stable populations are located in four Spanish regions: Andalusia with 755 specimens (43.6% of the Spanish population), closely followed by Castilla-La Mancha with 715 lynxes (41.3%), Extremadura where 253 specimens were located, and Murcia with seven.

Expansion of the Iberian lynx, in a graph provided by the Ministry for the Ecological TransitionExpansion of the Iberian lynx, in a graph provided by the Ministry for the Ecological TransitionMinisterio para la Transición Ecológica

The ministry believes that the data allow for a degree of optimism, because the feline’s trend is positive and has continued on an upward trend since 2015, the year in which the International Union for Conservation of Nature (IUCN) lowered its threat level. The species went from being “critically endangered” to simply “endangered.” It was a fundamental step for the survival of an animal that was close to extinction in 2002, when only 94 specimens remained in Andalusia. Captive breeding programs with significant European investment have allowed the creation of different nuclei, and have managed to reverse the situation. This increase now means that lynxes are approaching inhabited places, as happened in late March, when a rancher found four lynxes born in his haystack in Menasalbas, municipality of Toledo.

“We are at an average growth of 20%, a trend that has been maintained due to the creation of three new nuclei,” says Ramón Pérez de Ayala, a member of World Wildlife Fund (WWF) and a specialist in the species. To obtain the number of breeding females, it is necessary, according to their calculations, to create another five new areas with lynxes. “There were populations that grew a lot, up to 30%, but then they stabilized,” he explains. This occurred in the mountains of Toledo, one of the biggest success stories of reintroduction. “There, the first place where they became active was practically saturated, but the lynxes have moved to a neighboring area, which has kept up the growth,” he notes. The same situation has taken place in other areas such as Guarrizas (Jaén) and in Portugal, in the Guadiana valley area.

A reproductive female needs a territory of about 500 hectares, although it all depends on the amount of food available: the more food there is, the less space is needed. The rabbit is the main component of their diet and there are places where the rabbit population cannot recover, affected mainly by a deadly hemorrhagic disease. Depending on the areas, the drop is between 30% and 87% in a decade, indicates Pérez de Ayala. In this boom situation, the feline’s biggest enemy is road accidents, which has become its main cause of mortality. “In 2023 there were 144 deaths due to this cause, 7.1% of the population, and we cannot forget poaching, which goes unnoticed.”

Sign up for our weekly newsletter to get more English-language news coverage from EL PAÍS USA Edition

RISC vs. CISC by John R. Mashey (1995)

yarchive.net - Comments

Index Home About Blog
Newsgroups: comp.arch
From: [email protected] (John R. Mashey)
Subject: Re: Exception handling in PowerPC [no: RISC-vs-CISC, one more time]
Message-ID: <[email protected]>
Date: Tue, 28 Feb 1995 21:11:47 GMT

In article <[email protected]>, [email protected]
(DanHicks) writes:

|> >>>
|> Oh?  Consider the problem of designing exception handling for the P6.
|> It's pipelining, out-of-order and speculative execution that make
|> exception handling tough, and both the CISC and RISC people are doing
|> as much of this as they can.  It has little to do with the instruction
|> set.
|> <<<
|> 
|> True, but, as you point out, the distinction between RISC and CISC is
|> disappearing, to the point where the main distinction is psychological. 
|> And that's the biggest problem:  The RISC designers can't be convinced of
|> the importance of designing an architecture suited for something other
|> than benchmarks, whereas the CISC designers realize that accommodating
|> operating system requirements is a critical part of their job.

1) Attached is the Nth repost of the discussion of RISC-vs-CISC
non-convergence, i.e., architecture != implementation, one more time.
If you've followed this newsgroup for a while, you've seen this before.
I have included some followon discussions, and done minuscule editing.

2) The comments about RISC designers above are simply wrong;
"All generalizations are false", but especially this one.

3) re: Exception-handling: as I've noted for years in public talks (the
"Car" talk especially), tricky exception-handling is the price for
machines with increased parallelism and overlap.  Errat sheets are
customarily filled with bugs around exception cases.  Oddly enough,
speculative-execution, o-o-o machines may actually fare better than
you'd think, given that they already need mechanisms for undoinbg
(more-or-less) completed instructions.  From history, recall that the
360/91, circa 1967, had some imprecise exceptions, as did the 360/67
(early 360 with virtual memory), so exciting exception handling have
been with us for a while.

====REPOST====
Article 22850 of comp.arch:
Path: mips!mash
Subject: Nth re-posting of CISC vs RISC (or what is RISC, really)
Message-ID: <[email protected]>

Most of you have seen most of this several times before; there is a
little editing, nothing substantial.  Some followup comments have been
added.


PART I - ARCHITECTURE, IMPLEMENTATION, DIFFERENCES
PART II - ADDRESSING MODES
PART III - MORE ON TERMINOLOGY; WOULD YOU CALL THE CDC 6600 A RISC?
PART IV - RISC, VLIW, STACKS


PART I - ARCHITECTURE, IMPLEMENTATION, DIFFERENCES

WARNING: you may want to print this one to read it...
(from preceding discussion):
>Anyway, it is not a fair comparison.  Not by a long stretch.  Let's see
>how the Nth generation SPARC, MIPS, and 88K's do (assuming they last)
>compared to some new design from scratch.

Well, there is baggage and there is BAGGAGE.
One must be careful to distinguish between ARCHITECTURE and IMPLEMENTATION:
	a) Architectures persist longer than implementations, especially
	user-level Instruction-Set Architecture.
	b) The first member of an architecture family is usually designed
	with the current implementation constraints in mind, and if you're
	lucky, software people had some input.
	c) If you're really lucky, you anticipate 5-10 years of technology
	trends, and that modifies your idea of the ISA you commit to.
	d) It's pretty hard to delete anything from an ISA, except where:
		1) You can find that NO ONE uses a feature
			(the 68020->68030 deletions mentioned by someone
			else).
		2) You believe that you can trap and emulate the feature
		"fast enough".
			i.e., microVAX support for decimal ops,
			68040 support for transcendentals.
Now, one might claim that the i486 and 68040 are RISC implementations
of CISC architectures .... and I think there is some truth to this,
but I also think that it can confuse things badly:

Anyone who has studied the history of computer design knows that
high-performance designs have used many of the same techniques for years,
for all of the natural reasons, that is:
	a) They use as much pipelining as they can, in some cases, if this
	means a high gate-count, then so be it.
	b) They use caches (separate I & D if convenient).
	c) They use hardware, not micro-code for the simpler operations.
(For instance, look at the evolution of the S/360 products.
Recall that the 360/85 used caches, back around 1969, and within a few
years, so did any mainframe or supermini.)

So, what difference is there among machines if similar implementation
ideas are used?
A: there is a very specific set of characteristics shared by most
machines labeled RISCs, most of which are not shared by most CISCs.
The RISC characteristics:
	a) Are aimed at more performance from current compiler technology
	(i.e., enough registers).
OR
	b) Are aimed at fast pipelining
		in a virtual-memory environment
		with the ability to still survive exceptions
		without inextricably increasing the number of gate delays
		(notice that I say gate delays, NOT just how many gates).

Even though various RISCs have made various decisions, most of them have
been very careful to omit those things that CPU designers have found
difficult and/or expensive to implement, and especially, things that
are painful, for relatively little gain.

I would claim, that even as RISCs evolve, they may have certain baggage
that they'd wish weren't there .... but not very much.
In particular, there are a bunch of objective characteristics shared by
RISC ARCHITECTURES that clearly distinguish them from CISC architectures.

I'll give a few examples, followed by the detailed analysis:

MOST RISCs:
	3a) Have 1 size of instruction in an instruction stream
	3b) And that size is 4 bytes
	3c) Have a handful (1-4) addressing modes) (* it is VERY
	hard to count these things; will discuss later).
	3d) Have NO indirect addressing in any form (i.e., where you need
	one memory access to get the address of another operand in memory)
	4a) Have NO operations that combine load/store with arithmetic,
	i.e., like add from memory, or add to memory.
	(note: this means especially avoiding operations that use the
	value of a load as input to an ALU operation, especially when
	that operation can cause an exception.  Loads/stores with
	address modification can often be OK as they don't have some of
	the bad effects)
	4b) Have no more than 1 memory-addressed operand per instruction
	5a) Do NOT support arbitrary alignment of data for loads/stores
	5b) Use an MMU for a data address no more than once per instruction
	6a) Have >=5 bits per integer register specifier
	6b) Have >= 4 bits per FP register specifier
These rules provide a rather distinct dividing line among architectures,
and I think there are rather strong technical reasons for this, such
that there is one more interesting attribute: almost every architecture
whose first instance appeared on the market from 1986 onward obeys the
rules above .....
	Note that I didn't say anything about counting the number of
	instructions....
So, here's a table:
C: number of years since first implementation sold in this family
(or first thing which with this is binary compatible).
Note: this table was first done in 1991, so year = 1991-(age in table).
3a: # instruction sizes
3b: maximum instruction size in bytes
3c: number of distinct addressing modes for accessing data (not jumps)>
I didn't count register or
literal, but only ones that referenced memory, and I counted different
formats with different offset sizes separately.  This was hard work...
Also, even when a machine had different modes for register-relative and
PC_relative addressing, I counted them only once.
3d: indirect addressing: 0: no, 1: yes
4a: load/store combined with arithmetic: 0: no, 1:yes
4b: maximum number of memory operands
5a: unaligned addressing of memory references allowed in load/store,
	without specific instructions
	0: no never (MIPS, SPARC, etc)
	1: sometimes (as in RS/6000)
	2: just about any time
5b: maximum number of MMU uses for data operands in an instruction
6a: number of bits for integer register specifier
6b: number of bits for 64-bit or more FP register specifier,
	distinct from integer registers

Note that all of these are ARCHITECTURE issues, and it is usually quite
difficult to either delete a feature (3a-5b) or increase the number
of real registers (6a-6b) given an initial isntruction set design.
(yes, register renaming can help, but...)

Now: items 3a, 3b, and 3c are an indication of the decode complexity
	3d-5b hint at the ease or difficulty of pipelining, especially
	in the presence of virtual-memory requirements, and need to go
	fast while still taking exceptions sanely
	items 6a and 6b are more related to ability to take good advantage
	of current compilers.
	There are some other attributes that can be useful, but I couldn't
	imagine how to create metrics for them without being very subjective;
	for example "degree of sequential decode", "number of writebacks
	that you might want to do in the middle of an instruction, but can't,
	because you have to wait to make sure you see all of the instruction
	before committing any state, because the last part might cause a
	page fault,"  or "irregularity/assymetricness of register use",
	or "irregularity/complexity of instruction formats".  I'd love to
	use those, but just don't know how to measure them.
	Also, I'd be happy to hear corrections for some of these.

So, here's a table of 12 implementations of various architectures,
one per architecture, with the attributes above.  Just for fun, I'm
going to leave the architectures coded at first, although I'll identify
them later.  I'm going to draw a line between H1 and L4 (obviously,
the RISC-CISC Line), and also, at the head of each column, I'm going
to put a rule, which, in that column, most of the RISCs obey.
Any RISC that does not obey it is marked with a +; any CISC that DOES
obey it is marked with a *.  So...
	1991
CPU	Age	3a 3b 3c 3d	4a 4b 5a 5b	6a 6b	# ODD
RULE	<6	=1 =4 <5 =0	=0 =1 <2 =1	>4 >3
-------------------------------------------------------------------------
A1	4	 1  4  1  0	 0  1  0  1	 8  3+	1
B1	5	 1  4  1  0	 0  1  0  1	 5  4	-
C1	2	 1  4  2  0	 0  1  0  1	 5  4	-
D1	2	 1  4  3  0	 0  1  0  1	 5  0+	1
E1	5	 1  4 10+ 0	 0  1  0  1	 5  4	1
F1	5	 2+ 4  1  0	 0  1  0  1	 4+ 3+	3
G1	1	 1  4  4  0	 0  1  1  1	 5  5   -
H1	2	 1  4  4  0	 0  1  0  1	 5  4	-	RISC
---------------------------------------------------------------
L4	26	 4  8  2* 0*	 1  2  2  4	 4  2	2	CISC
M2	12	12 12 15  0*	 1  2  2  4	 3  3	1
N1	10	21 21 23  1	 1  2  2  4	 3  3	-
O3	11	11 22 44  1	 1  2  2  8	 4  3	-
P3	13	56 56 22  1	 1  6  2 24	 4  0	-

An interesting exercise is to analyze the ODD cases.
First, observe that of 12 architectures, in only 2 cases does an
architecture have an attribute that puts it on the wrong side of the line.
Of the RISCs:
-A1 is slightly unusual in having more integer registers, and less FP
than usual.  [Actually, slightly out of date, 29050 is different,
using integer register bank instead, I hear.]
-D1 is unusual in sharing integer and FP registers (that's what the
D1:6b == 0).
-E1 seems odd in having a large number of address modes.  I think most of this
is an artifact of the way that I counted, as this architecture really only
has a fundamentally small number of ways to create addresses, but has several
different-sized offsets and combinations, but all within 1 4-byte instruction;
I believe that it's addressing mechanisms are fundamentally MUCH simpler
than, for example, M2, or especially N1, O3, or P3, but the specific number
doesn't capture it very well.
-F1 .... is not sold any more.
-H1 one might argue that this process has 2 sizes of instructions,
but I'd observe that at any point in the instruction stream, the instructions
are either 4-bytes long, or 8-bytes long, with the setting done by a mode bit,
i.e., not dynamically encoded in every instruction.

Of the processors called CISCs:
-L4 happens to be one in which you can tell the length of the instruction
from the first few bits, has a fairly regular instruction decode,
has relatively few addressing modes, no indirect addressing.
In fact, a big subset of its instructions are actually fairly RISC-like,
although another subset is very CISCy.
-M2 has a myriad of instruction formats, but fortunately avoided
indirect addressing, and actually, MOST of instructions only have 1
address, except for a small set of string operations with 2.
I.e., in this case, the decode complexity may be high, but most instructions
cannot turn into multiple-memory-address-with-side-effects things.
-N1,O3, and P3 are actually fairly clean, orthogonal architectures, in
which most operations can consistently have operands in either memory or
registers, and there are relatively few weirdnesses of special-cased uses
of registers.  Unfortunately, they also have indirect addressing,
instruction formats whose very orthogonality almost guarantees sequential
decoding, where it's hard to even know how long an instruction is until
you parse each piece, and that may have side-effects where you'd like to
do a register write-back early, but either:
	must wait until you see all of the instruction until you commit state
or
	must have "undo" shadow-registers
or
	must use instruction-continuation with fairly tricky exception
	handling to restore the state of the machine
It is also interesting to note that the original member of the family to
which O3 belongs was rather simpler in some of the critical areas,
with only 5 instruction sizes, of maximum size 10 bytes, and no indirect
addressing, and requiring alignment (i.e., it was a much more RISC-like
design, and it would be a fascinating speculation to know if that
extra complexity was useful in practice).
Now, here's the table again, with the labels:
	1991
CPU	Age	3a 3b 3c 3d	4a 4b 5a 5b	6a 6b	# ODD
RULE	<6	=1 =4 <5 =0	=0 =1 <2 =1	>4 >3
-------------------------------------------------------------------------
A1	4	 1  4  1  0	 0  1  0  1	 8  3+	1	AMD 29K
B1	5	 1  4  1  0	 0  1  0  1	 5  4	-	R2000
C1	2	 1  4  2  0	 0  1  0  1	 5  4	-	SPARC
D1	2	 1  4  3  0	 0  1  0  1	 5  0+	1	MC88000
E1	5	 1  4 10+ 0	 0  1  0  1	 5  4	1	HP PA
F1	5	 2+ 4  1  0	 0  1  0  1	 4+ 3+	3	IBM RT/PC
G1	1	 1  4  4  0	 0  1  1  1	 5  5   -	IBM RS/6000
H1	2	 1  4  4  0	 0  1  0  1	 5  4	-	Intel i860
---------------------------------------------------------------
L4	26	 4  8  2* 0*	 1  2  2  4	 4  2	2	IBM 3090
M2	12	12 12 15  0*	 1  2  2  4	 3  3	1	Intel i486
N1	10	21 21 23  1	 1  2  2  4	 3  3	-	NSC 32016
O3	11	11 22 44  1	 1  2  2  8	 4  3	-	MC 68040
P3	13	56 56 22  1	 1  6  2 24	 4  0	-	VAX

General comment: this may sound weird, but in the long term, it might
be easier to deal with a really complicated bunch of instruction
formats, than with a complex set of addressing modes, because at least
the former is more amenable to pre-decoding into a cache of
decoded instructions that can be pipelined reasonably, whereas the pipeline
on the latter can get very tricky (examples to follow).  This can lead to
the funny effect that a relatively "clean", orthogonal archiecture may actually
be harder to make run fast than one that is less clean.  Obviously, every
weirdness has it's penalties....  But consider the fundamental difficulty
of pipelining something like (on a VAX):
	ADDL	@(R1)+,@(R1)+,@(R2)+

(I.e., something that, might theoretically arise from:
	register **r1, **r2;
	**r2++ = **r1++ + **r1++;

Now, consider what the VAX has to do:
1) Decode the opcode (ADD)
2) Fetch first operand specifier from I-stream and work on it.
	a) Compute the memory address from (r1)
		If aligned
			run through MMU
				if MMU miss, fixup
			access cache
				if cache miss, do write-back/refill
		Elseif unaligned
			run through MMU for first part of data
				if MMU miss, fixup
			access cache for that part of data
				if cache miss, do write-back/refill
			run through MMU for second part of data
				if MMU miss, fixup
			access cache for second part of data
				if cache miss, do write-back/refill
		Now, in either case, we now have a longword that has the
		address of the actual data.
	b) Increment r1  [well, this is where you'd LIKE to do it, or
	in parallel with step 2a).]  However, see later why not...
	c) Now, fetch the actual data from memory, using the address just
	obtained, doing everything in step 2a) again, yielding the
	actual data, which we needto stick in a temporary buffer, since it
	doesn't actually go in a register.
3) Now, decode the second operand specifier, which goes thru everything
that we did in step 2, only again, and leaves the results in a second
temporary buffer. Note that we'd like to be starting this before we get
done with all of 2 (and I THINK the VAX9000 probably does that??) but
you have to be careful to bypass/interlock on potential side-effects to
registers .... actually, you may well have to keep shadow copies of
every register that might get written in the instruction, since every
operand can use auto-increment/decrement. You'd probably want badly to
try to compute the address of the second argument and do the MMU
access interleaved with the memory access of the first, although the
ability of any operand to need 2-4 MMU accesses probably makes this
tricky.  [Recall that any MMU access may well cause a page fault....]

4) Now, do the add. [could cause exception]

5) Now, do the third specifier .... only, it might be a little different,
depending on the nature of the cache, that is, you cannot modify cache or
memory, unless you know it will complete.  (Why? well, suppose that
the location you are storing into overlaps with one of the indirect-addressing
words pointed to by r1 or 4(r1), and suppose that the store was unaligned,
and suppose that the last byte of the store crossed a page boundary and
caused a page fault, and that you'd already written the first 3 bytes.
If you did this straightforwardly, and then tried to restart the
instruction, it wouldn't do the same thing the second time.

6) When you're sure all is well, and the store is on its way, then you
can safely update the two registers, but you'd better wait until the end,
or else, keep copies of any modified registers until you're sure it's safe.
(I think both have been done ??)

7) You may say that this code is unlikely, but it is legal, so the CPU must
do it.  This style has the following effects:
	a) You have to worry about unlikely cases.
	b) You'd like to do the work, with predictable uses of functional
	units, but instead, they can make unpredictable demands.
	c) You'd like to minimize the amount of buffering and state,
	but it costs you in both to go fast.
	d) Simple pipelining is very, very tough: for example, it is
	pretty hard to do much about the next instruction following the
	ADDL, (except some early decode, perhaps), without a lot of gates
	for special-casing.
	(I've always been amazed that CVAX chips are fast as they are,
	and VAX 9000s are REALLY impressive...)
	e) EVERY memory operand can potentially cause 4 MMU uses,
	and hence 4 MMU faults that might actually be page faults...
	f) AND there are even worse cases, like the addp6 instruction, that
	can require *40* pages to be resident to complete... 
8) Consider how "lazy" RISC designers can be:
	a) Every load/store uses exactly 1 MMU access.
	b) The compilers are often free to re-arrange the order, even across
	what would have been the next instruction on a CISC.
	This gets rid of some stalls that the CISC may be stuck with
	(especially memory accesses).
	c) The alignment requirement avoids especially the problem with
	sending the first part of a store on the way before you're SURE
	that the second part of it is safe to do.

Finally, to be fair, let me add the two cases that I knew of that were more
on the borderline: i960 and Clipper:
CPU	Age	3a 3b 3c 3d	4a 4b 5a 5b	6a 6b	# ODD
RULE	<6	=1 =4 <5 =0	=0 =1 <2 =1	>4 >3
-------------------------------------------------------------------------
J1	5	 4+ 8+ 9+ 0      0  1  0  2      4+ 3+	5	Clipper
K1	3	 2+ 8+ 9+ 0	 0  1  2+ -      5  3+	5	Intel 960KB

(I think an ARM would be in this area as well; I think somebody once
sent me an ARM-entry, but I can't find it again; sorry.)


Note: slight modification (I'll integrate this sometime):


From [email protected]  Mon Nov 29 12:59:55 1993
Subject: Re: Why are Motorola's slower than Intel's ? [really what's a RISC]
Newsgroups: comp.arch
Organization: Massachusetts Institute of Technology

Since you made your table IBM has released a couple chips that support
unaligned accesses in hardware even across cache line boundaries and
may store part of an unaligned object before taking a page fault on
the second half, if the object crosses a page boundary.

These are the RSC (single chip POWER) and PPC 601 (based on RSC core).
    John Carr ([email protected])

(Back to me; jfc's comments are right; if I had time, I'd add another
line to do PPC ... which, in some sense replays the S/360 -> S/370
history of relaxing alignment restrictions somewhat.  I conjecture that
at least some of this was done to help Apple s/w migration.)


SUMMARY:
	1) RISCs share certain architectural characteristics, although there
	are differences, and some of those differences matter a lot.
	2) However, the RISCs, as a group, are much more alike than the
	CISCs as a group.
	3) At least some of these architectural characteristics have fairly
	serious consequences on the pipelinability of the ISA, especially
	in a virtual-memory, cached environment.
	4) Counting instructions turns out to be fairly irrelevant:
		a) It's HARD to actually count instructions in a meaningful
		way... (if you disagree, I'll claim that the VAX is RISCier
		than any RISC, at least for part of its instruction set :-)
		Why: VAX has a MOV opcode, whereas RISCs usually have
	  	a whole set of opcodes for {LOAD/STORE} {BYTE, HALF, WORD}
		b) More instructions aren't what REALLY hurts you, anywhere
		near as much features that are hard to pipeline:
		c) RISCs can perfectly well have string-support, or decimal
		arithmetic support, or graphics transforms ... or lots of
		strange register-register transforms, and it won't cause
		problems .....  but compare that with the consequence of
		adding a single instruction that has 2-3 memory operands,
		each of which can go indirect, with auto-increments,
		and unaligned data...

PART II - ADDRESSING MODES

Article: 30346 of comp.arch
Path: odin!mash.wpd.sgi.com!mash
Subject: Updated addressing mode table
Message-ID: <[email protected]>
Nntp-Posting-Host: mash.wpd.sgi.com

I promised to repost this with fixes, and people have been asking for it,
so here it is again: if you saw it before, all that's really different
is some fixes in the table, and a few clarified explanations:

THE GIANT  ADDDRESSING MODE TABLE (Corrections happily accepted)
This table goes with the higher-level table of general architecture
characteristics.

Address mode summary
r	register
r+	autoincrement (post)	[by size of data object]
-r	autodecrement (pre)	[by size,...and this was the one I meant]
>r	modify base register	[generally, effective address -> base]
				NOTE: sometimes this subsumes r+, -r, etc,
				and is more general, so I categorize it
				as a separate case.

d	displacement		d1 & d2 if 2 different displacements
x	index register
s	scaled index
a	absolute	[as a separate mode, as opposed to displacement+(0)
I	Indirect

Shown below are 22 distinct addressing modes [you can argue whether
these are right categories].  In the table are the *number* of different
encodings/variations [and this is a little fuzzy; you can especially
argue about the 4 in the HP PA column, I'm not even sure that's
right].  For example, I counted as different variants on a mode the
case where the structure was the same, but there were different-sized
displacements that had to be decoded.  Note that meaningfully counting
addressing modes is *at least as bad* as meaningfully counting opcodes;
I did the best I could, and I spect a lot of hours looking at manuals
for the chips I hadn't programmed much, and in some cases, even after
hours, it was hard for me to figure out meaningful numbers... *Most* of
these archiectures are used in general-purpose systems and *most* have
at least one version that uses caches: those are important because many
of the issues in thinking about addressing modes come from their
interactions with MMUs and caches... 


	1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20  21  22
							             r   r
						           r  r  r   +d1 +d1
	            r  r  r |              |   r  r |   r  r+ +d +d1 I   +s
	   r  r  r  +d +x +s|         s+ s+|s+ +d +d|r+ +d I  I  I   +s  I  
	r  +d +x +s >r >r >r|r+ -r a  a  r+|-r +x +s|I  I  +s +s +d2 +d2 +d2
	-- -- -- -- -- -- --|-- -- -- -- --|-- -- --|-- -- -- -- --- --- ---
AMD 29K	 1		    |		   |	    |   
Rxxx	    1		    |		   |	    |   
SPARC	    1  1  	    |		   |	    |   
88K         1  1  1	    |		   |	    |   
HP PA       2  1  1  4  1  1|		   |	    |   
ROMP     1  2		    |		   |	    |    
POWER       1  1     1  1   |		   |	    |    
i860        1  1     1  1   |		   |	    |    
Swrdfish 1  1  1	    |       1	   |	    |    
ARM      2  2     2  1     1| 1  1
Clipper  1  3  1            | 1  1  2      |	    |    
i960KB   1  1  1  1  	    |       2  2   |    1   |    

S/360       1  		    |		        1   |    
i486     1  3  1  1	    | 1  1  2      |    2  3|   
NSC32K      3		    | 1  1  3  3   |   	   3|    	  9 	  
MC68000  1  1		    | 1  1  2	   |	2   |
MC68020  1  1		    | 1  1  2	   |	2  4|  	      	      16  16
VAX	 1  3     1	    | 1  1  1  1  1| 1     3| 1  3  1  3  


COLUMN NOTES:

1) Columns 1-7 are addressing modes used by many machines, but very few,
if any clearly-RISC architectures use anything else.  They are all
characterized by what they don't have:
	2 adds needed before generating the address
	indirect addressing
	variable-sized decoding

2) Columns 13-15 include fairly simple-looking addressing modes, which however,
*may* require 2 back-to-back adds beforet he address is available.  [*may*
because some of them use index-register=0 or something to avoid
indexing, and usually in such machines, you'll see variable timing figures,
depending on use of indexing.]

3) Columns 16-22 use indirect addressing.

ROW NOTES
1) Clipper & i960, of current chips, are more on the RISC-CISC border,
or are sort of "modern CISCs".  ARM is also characterized (by ARM people,
Hot Chips IV: "ARM is not a "pure RISC".

2) ROMP has a number of characteristics different from the rest of the RISCs,
you might call it "early RISC", and it is of course no longer made.

3) You might consider HP PA a little odd, as it appears to have more
addressing modes, in the same way that CISCs do, but I don't think this
is the case: it's an issue of whether you call something several modes
or one mode with a modifier, just as there is trouble counting opcodes
(with & without modifiers).  From my view, neither PA nor POWER have
truly "CISCy" addressing modes.

4) Notice difference between 68000 and 68020 (and later 68Ks): a bunch of
incredibly-general & complex modes got added...

5) Note that the addressing on the S/360 is actually pretty simple,
mostly base+displacement, although RX-addressing does take 2 regs+offset.

6) A dimension *not* shown on this particular chart, but also highly
relevant, is that this chart shows the different *types* of modes, *not*
how many addresses can be found in each instruction.  That may be worth
noting also:
	AMD : i960	1	one address per instruction
	S/360 - MC68020	2	up to 2 addresses
	VAX		6	up to 6

By looking at alignment, indirect addressing,  and looking only at those
chips that have MMUs,
consider  the number of times an MMU *might* be used per instruction for
data address translations:
	AMD - Clipper	2		[Swordfish & i960KB: no TLB]
	S/360 - NSC32K	4
	MC68Ks (all)	8
	VAX		24

When RS/6000 does unaligned, it must be in the same cache line
(and thus also in same MMU page), and traps to software otherwise, thus
avoiding numerous ugly cases.

Note: in some sense, S/360s & VAXen can use an arbitrary number of translations
per instruction, with MOVE CHARACTER LONG, or similar operations & I don't
count them as more, because they're defined to be interruptable/restartable,
saving state in general-purpose registers, rather than hidden internal state.

SUMMARY:
1) Computer design styles mostly changed from machines with:
	2-6 addresses per instruction, with variable sized encoding
	address specifiers were usually "orthogonal", so that any could ggo
		anywhere in an instruction
	sometimes indirect addressing
	sometimes need 2 adds *before* effective address is available
	sometimes with many potential MMU accesses (and possible exceptions)
		per instruciton, often buried in the middle of the instruction,
		and often *after* you'd normally want to commit state because
		of auto-increment or other side effects.
to machines with:
	1 address per instruction
	address specifiers encoded in small # of bits in 32-bit instruction
	no indirect addressing
	never need 2 adds before address available
	use MMU once per data access

and we usually call the latter group RISCs.  I say "changed" because
if you put this table together with the earlier one, which has the
age in years, the older ones were one way, and the newer ones are different.

2)  Now, ignoring any other features, but looking at this single attribute
(architectural addressing features and implementation effects therof),
it ought to be clear that the machines in
the first part of the table are doing something *technically* different
from those in the second part of the table.  Thus, people may sometimes
call something RISC that isn't, for marketing reasons, but the people
calling the first batch RISC really did have some serious technical issues at
heart.

3) One more time: this is *not* to say that RISC is better than CISC,
or that the few in the middle are bad, or anything like that ... but
that there are clear technical characteristics...
  
PART III - MORE ON TERMINOLOGY; WOULD YOU CALL THE CDC 6600 A RISC?

Article: 39495 of comp.arch
Newsgroups: comp.arch
From: [email protected] (John R. Mashey)
Subject: Re: Why CISC is bad (was P6 and Beyond)
Organization: Silicon Graphics, Inc.
Date: Wed, 6 Apr 94 18:35:01 PDT

In article <[email protected]>, [email protected] (Andrea Chen) writes:

|> You may be correct on the creation of the term,  but RISC does
|> refer to a school of computer design that dates back to the
|> early seventies.

This is all getting fairly fuzzy and subjective, but it seems very confusing
to label RISC as a school of thought that dates back to the early 1970s.

1) One can say that RISC is a school of thought that got popular in the
early-to-mid 80's, and got widespread commercial use then.

2) One can say that there were a few people (like John Cocke & co at IBM)
who were doing RISC-style research projects in the mid-70s.

3) But if you want to go back, as has been discussed in this newsgroup often,
a lot of people go back to the CDC 6600, whose design started in 1960,
and was delivered in 4Q 1964.  Now, while this wouldn't exactly fit the
exact parameters of current RISCs, a great deal of the RISC-style approach
was there in the central processor ISA:
	a) Load/store architecture.
	b) 3-address register-register instructions
	c) Simply-decoded instruction set
	d) Early use of instructions schedule by compiler, expectation
	   that you'd usually program in high-level language and not often
	   resort to assembler, as you'd expect compiler to do well.
	e) More registers than common at the time
	f) ISA designed to make decode/issue easy

Note that the 360/91 (1967) offered a good example of building a
CISC-architecture into a high-performance machine, and was an interesting
comparison to the 6600.

4) Maybe there is some way to claim that RISC goes back to the 1950s,
but in general, most machines of the 1950s and 1960s don't feel very
RISCy (to me).  Consider Burroughs B5000s; IBM 709x, 707x, 1401s; Univac 110x;
GE 6xx, etc, and of course, S/360s.   Simple load/store architectures
were hard to find; there were often exciting instruction decodings required;
indirect addressing was popular; machines often had very few accumulators.

5) If you want to try sticking this in the matrix I've published before,
as best as I recall, the 6600 ISA generally looked like:

CPU		3a 3b 3c 3d	4a 4b 5a 5b	6a 6b	# ODD
RULE		=1 =4 <5 =0	=0 =1 <2 =1	>4 >3
-------------------------------------------------------------------------
CDC 6600	 2  *  1  0	 0  1  0  1	 3  3	4 (but  ~1 if fair)

That is:
2: it has 2 instruction sizes (not 1), 15 & 30 bits (however, were packed
into 60-bit words, so if you had 15, 30, 30, the second 30-bitter would not
cross word boundaries, but would start in the second word.)

*: 15-and-30 bit instructions, not 32-bit.

1: 1 addressing mode  [Note: Time McCaffrey emailed me that one might consider
	there to be more, i.e., you could set address register to combinations
	of the others to give autoincrement/decrement/Index+offset, etc).
	In any case, you compute an address as a simpel combination of 1-2
	registers, andthen use the address, without furhter side-effects.

0: no indirect addressing

1: have one memory operand per instruction

0: do NOT support arbitrary alignment of operands in memory
	(well, it was a word-addressed machine :-)

1: use an MMU for data translation no more than once per instruction
	(MMU used loosely here)

3,3: had 3-bit fields for addressing registers, both index and FP

Now, of the 10 ISA attributes I'd proposed for identifying typical RISCs,
the CDC 6600 obeys 6.  It varies in having 2 instruction formats, and in
having only 3 bits for register fields, but it had simple packing of the
instructions in to fixed-size words, and register/accumulators were
pretty expensive in those days (some popular machines only had one
accumulator and a few index registers, so 8 of each was a lot).  Put
another way: it had about as many registers as you'd conveniently build
in a high-speed machine, and while they packed 2-4 operations into a
60-bit word, the decode was pretty straighforward.  Anyway, given the
caveats, I'd claim that the 6600 would fit much better in the RISC part
of the original table...


PART IV - RISC, VLIW, STACKS

Article: 43173 of comp.arch
Newsgroups: comp.sys.amiga.advocacy,comp.arch
From: [email protected] (John R. Mashey)
Subject: Re: PG: RISC vs. CISC was: Re: MARC N. BARR
Date: Thu, 15 Sep 94 18:33:14 PDT

In article <[email protected]>, [email protected] writes:

|> Really? The Venerable John Mashey's table appears to contain as many
|> exceptions to the rule about number of GP registers as most others.
|> I'm sure if one were to look at the various less conventional
|> processors, there would be some clearly RISC processors that didn't
|> have a load-store architecture - stack and VLIW processors spring to
|> mind.

I'm not sure I understand the point.  One can believe any of several
things:
	a) One can believe RISC is some marketing term without technical
	   meaning whatsoever.  OR
	
	b) One can believe that RISC is some collection of implementation
	   ideas.  This is the most common confusion.
	
	c) One can believe that RISC has some ISA meaning (such as RISC ==
	   small number of opcodes) ... but have a different idea of RISC
	   than do most chip architects who build them.  If you want to pay
	   words extra money every Friday to mean something different than
	   what they mean to practitioners ... then you are free to do so,
	   but you will have difficulty communicating with practitioners
	   if you do so.
	   EX: I'm not sure how stack architectures are "clearly RISC" (?)
	   Maybe CRISP, sort of.  Burroughs B5000 or Tandem's original
	   ISA: if those are defined as RISC, the term has been rendered
	   meaningless.
	   EX: VLIWs: I don't know any reason why I'd call VLIWs, in
	   general, either clearly RISC or clearly not.  VLIW is a technique
	   for issuing instructions to more functional units than you
	   have the die space/cycle time to decode more dynamically.
	   There gets to be a fuzzy line between:
		a) A VLIW, especially if it compresses instructions in
		   memory, then expands them otu when brought into the cache.
		b) A superscalar RISC, which does some predecoding on the
		   way from memory->cache, adding "hint" bits or rearranging
		   what it keeps there, speeding up cache->decode->issue.
	   At least some VLIWs are load/store architectures, and the operations
	   they do look usually look like typical RISC operations.
	OR, you can believe that:

	c) RISC is a term used to characterize a class of relatively-similar
	ISAs mostly developed in the 1980s.  Thus, if a knowledgable
	person looks at ISAs, they will tend to cluster various ISAs
	as:
		1) Obvious RISC, fits the typical rules with few exceptions.
		2) Obviously not-RISC, fits the inverse of the RISC
		   rules with relatively few exceptions.  Sometimes
		   people call this CISC ... but whereas RISCs, as a group,
		   have realitvely similar ISAs, the CISC label is sometimes
		   applied to a widely varying st of ISAs.
		3) Hybrid / in-the-middle cases, that either look like
		   CISCy RISCs, or RISCy CISCs.  There are a few of these.
	Cases 1-3 are appropriate may apply to reasonably contemporaneous
		processors, and make some sense.  and then 4)
		4) CPUs for which RISC/CISC is probably not a very relevant
		   classification.  I.e., one can apply the set of rules
		   I've suggested, and get an exception-count, but it
		   may not mean much in practice, especially when
		   applied to older CPUs created with vastly different
		   constraints than current ones, or embedded
		   processors, or specialized ones.  Sometimes an older
		   CPU might have been designed with some similar
		   philosophies (i.e., like CDC 6600 & RISC, sort of)
		   whether or not it happend to fit the rules.
		   Sometimes, die-space constraints my have led to
		   "simple" chips, without making them fit the suggested
		   criteria either.  personally, torturous arguments
		   about whether a 6502, or a PDP-8, or a 360/44 or an
		   XDS Sigma 7, etc, are RISC or CISC ... do not
		   usually lead to great insight.  After a while such
		   arguments are counting angels dancing on pinheads
		   ("Ahh, only 10 angels, must be RISC" :-).
	In this belief space, one tends to follow Hennessy & Patterson's
	comment in E.9 that "In the history of computing, there has never
	been such widespread agreement on computer architecture."
	None of this pejorative of earlier architectures, just the observation
	that the ISAs newly-developed in the 1980s were far more similar
	that the earlier groups of ISAs.  [I recall a 2-year period in
	which I used IBM 1401, IBM 7074, IBM 7090, Univac 1108, and
	S/360, of which only the 7090 and 1108 bore even the remotest
	resemblance to each other, i.e., at least they both had 36-bit words.]

Summary: RISC is a label most commonly used for a set of ISA characteristics
chosen to ease the use of aggressive implementation techniques found in
high-performance processors (regardless of RISC, CISC, or irrelevant).
This is a convenient shorthand, but that's all, although it probably makes
sense to use the term thae way it's usually meant by people who do chips for
a living.
 
-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    [email protected] 
DDD:    415-390-3090	FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

From: [email protected] (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: Who started RISC? [really:RISC & CISC are different kinds of 
	words]
Date: 23 Jun 1995 20:38:19 GMT
Organization: Silicon Graphics, Inc.

In article <[email protected]>, [email protected] (John
Ahlstrom) writes:

|> : ifetch/decode/execute stages, and then Cray & Thornton perfected in the
|> : CDC 6400 & 6600 what we now call superpipelined RISC machines.  This

|> They were certainly RISCy (who coined THAT wonderful term?) were they
|> RISC?  Let's ask Mashey.

1) This has come up before & I talked about it in PART III of the usual
big "What is RISC" thing that I repost now and then.  My answer was that
while it didn't exactly fit the architectural parameters of classic RISC,
it would generally have fit more in the RISC part of the table.

2) However, some of this whole thread has gotten a little crazy:

	a) The term RISC, used properly, turns out to be a useful description
	for a set of ISAs that:
		- Were designed at roughly the same time
		- Shared at least some assumptions in software and hardware
			technology.
		- Have enough similarities that they form a relatively tight
		  "cluster" in the space of all ISAs.  (The big posting
		   described some of these attributes).

	b) Put another way, it has been the case that if somebody said they
	   had designed a RISC CPU, and knew what they were talking about,
	   and you knew nothing else about it, you'd guess that it would have
	   32-bit instructions, load/store architecture, simple addressing
	   modes, 32-bit integer registers (or the obvious 64-bit extensions),
	   separate integer and FP rgisters, etc ...
	   and you'd probably mostly guess right.

	   At some point, trying to argue whether or not a 30-year-old
	   CPU was RISC or not is counting angels dancing on pinheads,
	   that is, it is not useful.  It might be useful to consider the
	   various specific attributes of ISAs and see what was there.

	   Just because a CPU has a low gate-count doesn't make it RISC ...
	   but it is also not clear that calling it CISC tells you much, since:

	c) CISC is *not* a term like RISC, i.e., I think it was invented
	   to mean "not-RISC", and people often use it that way, thus
	   including the entire architectural space *except* that little
	   cluster properly labeled RISC.  [Note: this is not a pejorative
	   comment on the term CISC, just a note that people often use
	   a RISC-vs-CISC style argument as though the two terms had the
	   same nature ... and they don't].  For example, suppose someone
	   tells you they've worked on a CISC.  What would you know about
	   the nature of that ISA?
		Would it have a range of instruction sizes?
			maybe ... but there have been plenty of ISAs with
			a single instruction size that would be very hard
			to call RISCs.
		Would it have indirect addressing, and if so, 1-level,
			or multi-level?
			Maybe, maybe not [S360's don't].
		Would it have separate integer and FP registers?
			Maybe, maybe not. [VAX's don't]
		Would it be a General Register Machine, a stack machine,
			or some kind of memory-memory machine?
			Completely unclear.
	   Thus, there are a bunch of relatively similar ISAs called RISCs;
	   there are a much larger bunch called CISCs, that often have little
	   in common.  There are a few that lie on the border, in some
	   multi-dimensional space of ISA attributes.

	d) As a result, it is fairly difficult (for me) to make much sense of
	arguments about which machines are RISCier or CISCier - I don't
	know of any natural linear scale of such things [recall that the
	charts I've posted explicitly avoided computing a single RISC/CISC
	number].

Anyway, it certainly seemed to me that Seymour Cray had some of the same
approach as later RISC designers, but that the current RISC wave especially
started with John Cocke & co at T. J. Watson.
		 


-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    [email protected] 
DDD:    415-390-3090	FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311

Index Home About Blog

Classic Usenet posts on computer architecture, operating systems and languages

yarchive.net - Comments

Computer Architecture


The prospects for 128 bit processors (John R. Mashey) [8913 bytes]
64 bit processors: history and rationale (John R. Mashey) [32401 bytes]
AMD64 (Linus Torvalds; Terje Mathisen) [12514 bytes]
Asynchronous logic (Mitch Alsup) [3766 bytes]
Atomic transactions (Mitch Alsup; Terje Mathisen) [86188 bytes]
BCD instructions: RISC and CISC (John R. Mashey) [3624 bytes]
Big Data (John R. Mashey, Larry McVoy) [30027 bytes]
Byte_addressing (John R. Mashey) [2819 bytes]
Caches (John R. Mashey; John D. McCalpin) [7821 bytes]
Parity and ECC use in caches (John R. Mashey) [1549 bytes]
Cache thrashing (Andy Glew; Linus Torvalds; Terje Mathisen) [9422 bytes]
Carry bits; The Architect's Trap (John R. Mashey) [8038 bytes]
CMOS logic speeds (Mitch Alsup) [9317 bytes]
CMOV (Terje Mathisen) [2341 bytes]
CPU feature economics (John R. Mashey) [3860 bytes]
CPU power usage (Mitch Alsup) [2795 bytes]
Hardware to aid debugging (John R. Mashey) [10408 bytes]
DRAM cache (Mitch Alsup; Terje Mathisen) [8807 bytes]
DRAM latencies (Mitch Alsup) [3056 bytes]
Endian (John R. Mashey) [2053 bytes]
Separate floating point registers (John R. Mashey) [14584 bytes]
Floating-point exception fixup (John Mashey; Terje Mathisen) [6750 bytes]
Fault tolerant (John R. Mashey) [4384 bytes]
H264 CABAC (Maynard Handley; Terje Mathisen) [19556 bytes]
Merced/IA64 (John R. Mashey) [23688 bytes]
Instructions per clock (John R. Mashey) [7624 bytes]
IBM 801 (Greg Pfister) [5308 bytes]
Why the IBM PC used the 8088 (Bill Katz; John R. Mashey) [4264 bytes]
Interval arithmetic (James B. Shearer) [47593 bytes]
Lisp support (Eliot Miranda; John Mashey) [27352 bytes]
LL/SC (John Mashey; Terje Mathisen) [26317 bytes]
Message passing versus shared memory; the SGI Origin machines (John R. Mashey, John McCalpin) [73943 bytes]
MIPS16 (John R. Mashey) [3489 bytes]
Interrupts on the MIPS processors (John R. Mashey) [7035 bytes]
MIPS exceptions (John Mashey) [11018 bytes]
Misalignment (John Levine; Mitch Alsup; Terje Mathisen) [14100 bytes]
Multiprocessor machine terminology (John R. Mashey) [8226 bytes]
The MVC instruction (John R. Mashey, Allen J. Baum) [15584 bytes]
The definition of an N bit cpu (John R. Mashey) [4027 bytes]
Opteron STREAM benchmark optimizations (Terje Mathisen) [2030 bytes]
Page size (Linus Torvalds) [2775 bytes]
The Pentium 4 (Linus Torvalds; Terje Mathisen) [4681 bytes]
Why word sizes are powers of 2 (John R. Mashey) [5185 bytes]
PowerPC page tables (Greg Pfister; Linus Torvalds) [22229 bytes]
Prefetch (Terje Mathisen) [3788 bytes]
Quad precision (Robert Corbett) [989 bytes]
Register windows (John Mashey) [8389 bytes]
Register file size (Mitch Alsup) [5876 bytes]
REP MOVS (Terje Mathisen) [1160 bytes]
Register renaming (John R. Mashey) [4955 bytes]
Result forwarding (Terje Mathisen) [1524 bytes]
RISC vs CISC (John R. Mashey) [43955 bytes]
ROM speeds (Mitch Alsup) [1835 bytes]
Self-modifying code (John R. Mashey, John Reiser, Dennis Ritchie) [24900 bytes]
Direct Mapped vs. Set Associative caches (John R. Mashey) [2260 bytes]
Signed division (Robert Corbett) [1273 bytes]
Algorithm Analyses *Must Change* to Model Current Processors (John R. Mashey) [10337 bytes]
Software pipelining (Linus Torvalds) [23736 bytes]
Software-refilled TLBs (John R. Mashey, John F Carr) [76259 bytes]
The SPEC benchmark suite (John R. Mashey) [55015 bytes]
SpecFP2000 (Greg Lindahl; John D. McCalpin; Wesley Jones) [19554 bytes]
SpecFP bandwidth (John D. McCalpin) [8570 bytes]
SpecFP and time-skewing optimizations (Greg Lindahl; John D. McCalpin) [24362 bytes]
SRAM main memories (John R. Mashey) [3130 bytes]
Stack machines (John R. Mashey) [34138 bytes]
Streaming data (John R. Mashey) [4655 bytes]
The Tera multithreaded architecture (Preston Briggs, John R. Mashey) [27972 bytes]
Multithreaded CPUs (John R. Mashey) [11759 bytes]
TLBs (John Mashey) [9415 bytes]
Transmission gates (Mitch Alsup) [1686 bytes]
The VAX (John Mashey) [89376 bytes]
Vectored interrupts (John Mashey) [4607 bytes]
Virtual machines (John R. Mashey) [4749 bytes]
Wiz (John Mashey) [106300 bytes]
Zero registers (John R. Mashey) [32828 bytes]

Programming Languages


Ada (Henry Spencer) [3755 bytes]
Aliasing (Terje Mathisen) [1060 bytes]
Alloca (Dennis Ritchie) [2383 bytes]
The ANSI C unsigned mess (Chris Torek) [4523 bytes]
Array bounds checking (Henry Spencer) [4905 bytes]
Bad C macros (Jamie Lokier) [1768 bytes]
Caching multidimensional arrays (Terje Mathisen) [2469 bytes]
Call by name (John R. Mashey; Dennis Ritchie; Robert Corbett; William B. Clodius) [11927 bytes]
Binary calling conventions (Chris Torek) [17341 bytes]
C (Dennis Ritchie; Douglas A. Gwyn; John A. Gregor, Jr.; Linus Torvalds) [15080 bytes]
C calling conventions for main() (Dennis Ritchie) [1765 bytes]
C "extern" (Dennis Ritchie) [1659 bytes]
C prototypes (Chris Torek) [2396 bytes]
C shifts (Dennis Ritchie) [1428 bytes]
The C99 preprocessor (Al Viro) [2001 bytes]
C's == operator (Linus Torvalds) [2566 bytes]
COBOL (Henry Spencer; Morten Reistad; Terje Mathisen) [17966 bytes]
Compiler design (Henry Spencer) [13873 bytes]
Compiler optimizations (Andy Glew; Greg Lindahl; Linus Torvalds; Terje Mathisen) [13634 bytes]
COME FROM (Robert Corbett) [1738 bytes]
The "const" qualifier in C (Chris Torek; Linus Torvalds) [15452 bytes]
Contravariance (Henry Spencer) [4621 bytes]
Cray integers (Dennis Ritchie) [1695 bytes]
Debuggers (Douglas A. Gwyn) [1555 bytes]
Decimal FP (Glen Herrmannsfeldt; Mitch Alsup; Terje Mathisen; Wilco Dijkstra; [email protected]) [22994 bytes]
Denormals (Terje Mathisen) [1672 bytes]
Dereferencing null (John R. Mashey) [1254 bytes]
empty_statement macro (Linus Torvalds) [2636 bytes]
Fortran operator precedence weirdness (Robert Corbett) [1735 bytes]
F2K allocatable (Jos R Bergervoet; Richard Maine) [10487 bytes]
F2K optional arguments (Robert Corbett) [2801 bytes]
F90 arrays (James Van Buskirk; Richard Maine; Robert Corbett) [18144 bytes]
F90 (Richard Maine) [7143 bytes]
F95 (Robert Corbett) [6536 bytes]
Fast division (Terje Mathisen) [3397 bytes]
Floor function (Chris Torek) [3372 bytes]
Fortran ABI (Robert Corbett) [3899 bytes]
Fortran aliasing (James Van Buskirk; Jos Bergervoet; Richard Maine; Robert Corbett) [9377 bytes]
Fortran carriage control (Richard Maine) [5791 bytes]
Fortran extensions (Robert Corbett) [3265 bytes]
Fortran functions (Robert Corbett) [7644 bytes]
Fortran intent (Richard Maine; Robert Corbett) [9394 bytes]
Fortran parse (Robert Corbett) [2731 bytes]
Fortran pointers (Robert Corbett) [6712 bytes]
Fortran real*8 (Richard Maine; Robert Corbett) [3769 bytes]
Fortran standard (Charles Russell; Robert Corbett) [28776 bytes]
Fortran tabs (Robert Corbett) [1560 bytes]
GCC optimization (Chris Torek) [9693 bytes]
The GPL and linking (Theodore Y. Ts'o) [6738 bytes]
Handwritten parse tables (David R Tribble; Dennis Ritchie) [5340 bytes]
Integer lexing (Henry Spencer) [1249 bytes]
Java bytecode verification (David Chase) [2044 bytes]
Latency (John Mashey; Terje Mathisen) [4808 bytes]
LL parsing (Henry Spencer) [1525 bytes]
Logical XOR (Dennis Ritchie) [3288 bytes]
The 64-bit integer type "long long": arguments and history. (John R. Mashey) [77321 bytes]
longjmp() (Dennis Ritchie; Larry Jones) [6562 bytes]
malloc() (Chris Torek; David Chase) [8046 bytes]
Matrix multiplication (James B. Shearer) [1290 bytes]
Norestrict (Linus Torvalds) [18019 bytes]
Parsers (Henry Spencer) [8805 bytes]
Pl/I (John R. Levine) [5521 bytes]
Polyglot program (Peter Lisle) [6103 bytes]
Power-of-two detection (Bruce Hoult; John D. McCalpin) [2402 bytes]
Sequence points (Dennis Ritchie) [2365 bytes]
Shift instructions and the C language (John R. Mashey) [43881 bytes]
Signal handlers and errno (Chris Torek) [3571 bytes]
Square root of a matrix (Cleve Moler) [7489 bytes]
Standard readability (Henry Spencer) [6581 bytes]
String literals (Dennis Ritchie; Douglas A. Gwyn) [7264 bytes]
strtok (Chris Torek) [6787 bytes]
Struct return (Chris Torek) [7699 bytes]
Stupid pointer tricks (David E. Wallace) [5150 bytes]
The C "volatile" qualifier (John R. Mashey; Linus Torvalds; Theodore Tso) [92228 bytes]

The Computer Business; Miscellaneous


The chip making business (John R. Mashey) [30676 bytes]
Computer spending (John R. Mashey) [3943 bytes]
Copy protection (John De Armond) [4974 bytes]
Danish (Terje Mathisen) [1106 bytes]
English (Henry Spencer) [2154 bytes]
The ETA Saga (Rob Peglar) [38619 bytes]
Evolution (Linus Torvalds; Larry McVoy) [23087 bytes]
The Gulf Stream (Norman Yarvin) [10575 bytes]
High tech stocks (John R. Mashey) [19025 bytes]
Highways (John F. Carr) [2490 bytes]
Hospitals (del cecchi) [1955 bytes]
Insider Trading (John R. Mashey) [14009 bytes]
Media reports (John R. Mashey) [6087 bytes]
MIPS prospects (old) (John R. Mashey) [40572 bytes]
The MIPS stock glitch (John R. Mashey) [5395 bytes]
Mimeograph (Dennis Ritchie) [1818 bytes]
Norway (Terje Mathisen) [5549 bytes]
Oceanography (John D. McCalpin) [2423 bytes]
Out-of-print books and tax law (Henry Spencer) [1478 bytes]
Patents (John R. Mashey) [3195 bytes]
SGI Cray acquisition (John R. Mashey; John D. McCalpin) [14327 bytes]
SGI and high-end graphics (John R. Mashey, John F Carr) [18963 bytes]
SGI's customers (John R. Mashey) [24248 bytes]
SGI and the movies (John R. Mashey) [18218 bytes]
SGI and Windows NT (John R. Mashey) [8183 bytes]
Software patents (Dennis Ritchie) [2127 bytes]
High-tech innovation (John Mashey) [15334 bytes]
Bell Labs and stupid lawsuits (John R. Mashey) [2106 bytes]

Hardware


Bad blocks (Theodore Y. Ts'o) [20421 bytes]
Reseating circuit boards (Henry Spencer) [782 bytes]
Copper chip wires (Mitch Alsup) [1604 bytes]
Ethernet crossover cables (H. Peter Anvin) [1381 bytes]
Ethernet encoding (Henry Spencer) [1647 bytes]
Ethernet grounding (Henry Spencer) [1064 bytes]
The Ethernet patent (Henry Spencer) [1148 bytes]
IC desoldering (John De Armond) [1219 bytes]
Non-parity memory (Henry Spencer) [3248 bytes]
Optical fiber (Morten Reistad; Terje Mathisen) [37097 bytes]
RS232 signals (anon) [8585 bytes]
RS232 RTS/CTS lines (Henry Spencer) [2000 bytes]
Tales (anon) [2483 bytes]

Operating Systems


The Bourne shell (John R. Mashey) [11148 bytes]
BSD (Dennis Ritchie) [2329 bytes]
Deadlock (John Mashey) [5305 bytes]
EIO (Douglas A. Gwyn) [1170 bytes]
Ethernet checksums (Jonathan Stone; Linus Torvalds; Terje Mathisen) [28032 bytes]
An FTP security hole (*Hobbit*) [10500 bytes]
Large pages (John Mashey) [6866 bytes]
Microkernels (Linus Torvalds) [69856 bytes]
Minix (Linus Torvalds) [3597 bytes]
Memory mapping (John R. Mashey; Linus Torvalds) [14030 bytes]
Real time systems (John R. Mashey) [7952 bytes]
Sandboxes (Theodore Y. Ts'o) [3611 bytes]
Setuid mess (Casper H.S. Dik; Chris Torek) [14468 bytes]
Synchronous metadata (Linus Torvalds) [4283 bytes]
Unix command names (Henry Spencer) [2201 bytes]
Zombie processes (Douglas A. Gwyn) [1430 bytes]

Linux


64-bit divide (Jamie Lokier; Linus Torvalds) [5581 bytes]
ABI documentation (Linus Torvalds) [4882 bytes]
ACCESS_ONCE (Linus Torvalds) [6081 bytes]
ACKs (Linus Torvalds) [3634 bytes]
ACPI (Linus Torvalds) [2729 bytes]
Address zero (Linus Torvalds) [5707 bytes]
Antivirus software (Al Viro; Theodore Tso) [34379 bytes]
Assert (Linus Torvalds) [1716 bytes]
Asynchronous resume (Linus Torvalds) [82056 bytes]
Bayes spam filters (Linus Torvalds) [5412 bytes]
Benchmarks (Linus Torvalds) [7639 bytes]
Binary modules (Theodore Ts'o) [6344 bytes]
Bind mounts (Al Viro) [1094 bytes]
Dealing with the BIOS (Linus Torvalds) [16864 bytes]
BIOS boot order (H. Peter Anvin) [1316 bytes]
Bitfields (Linus Torvalds; Al Viro) [7167 bytes]
Block device error handling (Theodore Ts'o) [9824 bytes]
Block layer (Linus Torvalds) [7000 bytes]
Bool (H. Peter Anvin; Linus Torvalds) [10186 bytes]
Branch hints (Linus Torvalds) [10588 bytes]
Buffer heads (Linus Torvalds; Theodore Tso) [24461 bytes]
BUG() (Linus Torvalds) [19318 bytes]
Bug tracking (Linus Torvalds; Theodore Tso) [37198 bytes]
Build log diffs (Al Viro) [3477 bytes]
Bundling (Al Viro; Linus Torvalds) [15012 bytes]
Bytes-left-in-page macro (Linus Torvalds) [2343 bytes]
Cache coloring (Linus Torvalds) [12148 bytes]
Cache games (Linus Torvalds) [4809 bytes]
Caches and read-ahead (Daniel Phillips; H. Peter Anvin; Linus Torvalds) [33801 bytes]
Callback type safety (Al Viro) [10717 bytes]
Case insensitive filenames (H. Peter Anvin; Ingo Molnar; Linus Torvalds; Theodore Ts'o; Al Viro) [80356 bytes]
C++ (Al Viro; Linus Torvalds; Theodore Ts'o) [14772 bytes]
C support for concurrency (Linus Torvalds) [2164 bytes]
Checkpointing (Linus Torvalds) [3294 bytes]
Child-runs-first (Linus Torvalds) [2217 bytes]
chroot (Al Viro; Theodore Tso) [6538 bytes]
CLI/STI (Linus Torvalds) [1533 bytes]
close()'s return value (Linus Torvalds) [3174 bytes]
CMOV (Linus Torvalds) [11509 bytes]
cmpxchg, LL/SC, and portability (Al Viro; Linus Torvalds) [17064 bytes]
Code complexity (Linus Torvalds) [3470 bytes]
Code size (Linus Torvalds) [4288 bytes]
Coding style (Al Viro; Larry McVoy; Linus Torvalds; Theodore Tso) [64473 bytes]
Collective work copyright (Linus Torvalds) [9886 bytes]
Commit messages (Linus Torvalds) [3263 bytes]
Compatibility (Al Viro; Linus Torvalds; Theodore Ts'o) [36511 bytes]
Compatibility wrappers (Linus Torvalds) [4398 bytes]
Compiler barriers (Linus Torvalds) [4393 bytes]
Conditional assignments (Linus Torvalds) [2996 bytes]
CONFIG_LOCALVERSION_AUTO (Linus Torvalds) [2688 bytes]
CONFIG_PM_TRACE (Linus Torvalds) [2269 bytes]
Constant expressions (Al Viro; Linus Torvalds) [6373 bytes]
CPU reliability (Linus Torvalds) [1814 bytes]
Crash dumps (Linus Torvalds) [10477 bytes]
dd_rescue (Theodore Tso) [3060 bytes]
Deadlock (Greg KH; Linus Torvalds; Al Viro) [17432 bytes]
Debuggers (Al Viro; Larry McVoy; Linus Torvalds; Theodore Y. Ts'o) [28184 bytes]
Development speed (Al Viro; Linus Torvalds; Theodore Tso) [36071 bytes]
devfs (Al Viro; Theodore Ts'o) [23268 bytes]
Device numbers (H. Peter Anvin; Linus Torvalds; Theodore Ts'o; Al Viro) [45554 bytes]
Device probing (Linus Torvalds) [12511 bytes]
/dev permissions (Linus Torvalds) [1901 bytes]
/dev/random (H. Peter Anvin; Theodore Y. Ts'o) [85163 bytes]
Dirty limits (Linus Torvalds) [11525 bytes]
disable_irq races (Linus Torvalds; Al Viro) [26415 bytes]
Disk corruption (Theodore Ts'o;) [14162 bytes]
Disk snapshots (Theodore Tso) [1895 bytes]
Documentation (Linus Torvalds) [1406 bytes]
DRAM power savings (Linus Torvalds) [8571 bytes]
Drive caches (Linus Torvalds) [16400 bytes]
DRM (Linus Torvalds) [21104 bytes]
Dual license BSD/GPL (Linus Torvalds; Theodore Tso) [19263 bytes]
dump (Linus Torvalds) [11522 bytes]
e2image (Theodore Ts'o) [2631 bytes]
Edge-triggered interrupts (Linus Torvalds) [35208 bytes]
EFI (Linus Torvalds) [4192 bytes]
Empty function calls' cost (Linus Torvalds) [4194 bytes]
errno (Linus Torvalds) [2011 bytes]
Error jumps (Linus Torvalds) [2463 bytes]
Event queues (Linus Torvalds) [32863 bytes]
The everything-is-a-file principle (Linus Torvalds) [21195 bytes]
Execute-only (Linus Torvalds) [3927 bytes]
EXPORT_SYMBOL_GPL (Linus Torvalds) [1655 bytes]
Extreme system recovery (Al Viro) [6470 bytes]
Fairness (Ingo Molnar; Linus Torvalds; Ulrich Drepper) [24826 bytes]
File hole caching (Linus Torvalds) [1554 bytes]
Files as directories (Linus Torvalds; Theodore Ts'o; Al Viro) [118379 bytes]
Filesystem compatibility (Theodore Tso) [2204 bytes]
Flash card errors (H. Peter Anvin; Theodore Tso) [8266 bytes]
Fork race (Linus Torvalds) [2197 bytes]
Saving the floating-point state (Linus Torvalds) [10863 bytes]
Fragmentation avoidance (Linus Torvalds) [48733 bytes]
The framebuffer code (Linus Torvalds) [1931 bytes]
Frequency scaling (Linus Torvalds) [18171 bytes]
Function pointers (Linus Torvalds) [1056 bytes]
gcc assembly (Linus Torvalds) [13771 bytes]
gcc attributes (Al Viro; Linus Torvalds) [29806 bytes]
gcc (Al Viro; H. Peter Anvin; Linus Torvalds; Theodore Y. Ts'o) [139556 bytes]
gcc "inline" (H. Peter Anvin; Linus Torvalds; Theodore Tso) [86941 bytes]
gcc and kernel stability (Linus Torvalds) [15853 bytes]
Generic mechanisms (Linus Torvalds) [8581 bytes]
getpid() caching (Linus Torvalds) [15203 bytes]
get_unaligned() (Linus Torvalds) [4548 bytes]
git basic usage (Linus Torvalds) [8284 bytes]
git bisect (Linus Torvalds) [32500 bytes]
git branches (Linus Torvalds) [12910 bytes]
git btrfs history (Linus Torvalds) [3514 bytes]
git (Linus Torvalds; Theodore Ts'o) [87731 bytes]
Git merges from upstream (Linus Torvalds) [18183 bytes]
git rebase (Al Viro; Linus Torvalds; Theodore Tso) [101693 bytes]
Global variables (Theodore Tso) [1600 bytes]
The GPL3 (Al Viro; Linus Torvalds) [13983 bytes]
The GPL (Al Viro; Larry McVoy; Linus Torvalds; Theodore Ts'o) [150693 bytes]
The GPL and modules (Linus Torvalds; Theodore Ts'o; Al Viro) [94008 bytes]
Hardware glitches (Linus Torvalds) [9670 bytes]
Hibernation (Linus Torvalds) [110016 bytes]
Highmem (H. Peter Anvin; Linus Torvalds) [15703 bytes]
Hurd (Larry McVoy; Theodore Ts'o) [7205 bytes]
HZ (Linus Torvalds) [30583 bytes]
ifdefs (Linus Torvalds) [3225 bytes]
in_interrupt() (Linus Torvalds; Theodore Y. Ts'o) [3302 bytes]
Initramfs (Al Viro; Linus Torvalds) [5854 bytes]
Inline assembly (H. Peter Anvin; Linus Torvalds) [19062 bytes]
Inlining functions (Linus Torvalds) [17099 bytes]
Innovation (Al Viro) [3185 bytes]
Integer types in the kernel (Linus Torvalds; Al Viro) [5546 bytes]
ioctl() (Al Viro; Linus Torvalds) [27092 bytes]
I/O space accesses (Linus Torvalds) [16057 bytes]
IRQ routing (Linus Torvalds) [6371 bytes]
Journaling filesystems (Theodore Y. Ts'o) [5336 bytes]
Kernel configuration (Linus Torvalds; Theodore Tso) [29836 bytes]
Kernel deadlock debugging (Linus Torvalds) [4953 bytes]
Kernel dumps (Linus Torvalds; Theodore Tso) [5484 bytes]
Kernel floating-point (Linus Torvalds) [3517 bytes]
Kernel headers (Al Viro; H. Peter Anvin; Linus Torvalds) [41700 bytes]
The kernel's role (Linus Torvalds) [9704 bytes]
kinit (Al Viro; H. Peter Anvin; Linus Torvalds; Theodore Tso) [20839 bytes]
Large pages (Linus Torvalds) [16018 bytes]
Latency (Linus Torvalds) [2746 bytes]
libgcc (Linus Torvalds) [7604 bytes]
Light-weight processes (David S. Miller; Larry McVoy; Zack Weinberg) [31949 bytes]
Linus Torvalds (Linus Torvalds) [2335 bytes]
Linux development policy (Linus Torvalds) [2805 bytes]
Linux's speed (Linus Torvalds) [2297 bytes]
The Linux trademark (Linus Torvalds) [6140 bytes]
Lists (Linus Torvalds) [2515 bytes]
Lock costs (Linus Torvalds) [4814 bytes]
Locking (Linus Torvalds) [21406 bytes]
Lock ordering (Linus Torvalds) [3915 bytes]
Log structured filesystems (Theodore Tso) [7269 bytes]
Log timestamp ordering (Linus Torvalds) [12127 bytes]
Lookup tables (Linus Torvalds) [2508 bytes]
lost+found (Theodore Y. Ts'o) [2064 bytes]
Maintainers (Linus Torvalds) [39113 bytes]
malloc(0) (Linus Torvalds) [7643 bytes]
MAP_COPY (Linus Torvalds) [9843 bytes]
Massive cross-builds (Al Viro) [10643 bytes]
memcpy (Linus Torvalds) [1707 bytes]
Memory barriers (Linus Torvalds) [24459 bytes]
Memory pressure code (Linus Torvalds) [14078 bytes]
The merge window (Linus Torvalds) [18914 bytes]
Micro-optimizations (Linus Torvalds) [2426 bytes]
minixfs (Al Viro; Linus Torvalds) [12580 bytes]
mmap() portability (Linus Torvalds) [7131 bytes]
MODVERSIONS (Linus Torvalds) [7285 bytes]
More evil than... (Larry McVoy) [1254 bytes]
Mounts (Al Viro; Linus Torvalds) [9919 bytes]
mtime changes with mmap() (Linus Torvalds) [3649 bytes]
MTU discovery (Theodore Y. Ts'o) [11101 bytes]
Multiple includes (Linus Torvalds) [1304 bytes]
must_check (Linus Torvalds) [13071 bytes]
Negative dentries (Linus Torvalds) [2379 bytes]
Network filesystems (Al Viro) [2907 bytes]
NFS (Linus Torvalds) [4352 bytes]
NO_IRQ (Linus Torvalds) [7379 bytes]
NOP (Linus Torvalds) [2329 bytes]
O_DIRECT (Larry McVoy; Linus Torvalds) [52865 bytes]
Oops decoding (Al Viro; Linus Torvalds) [34176 bytes]
-Os (Linus Torvalds) [3063 bytes]
The page cache (Linus Torvalds) [5480 bytes]
Page coloring (Larry McVoy; Linus Torvalds) [6901 bytes]
Page sizes (Linus Torvalds) [29511 bytes]
Page tables (Linus Torvalds; Paul Mackerras) [43972 bytes]
Page zeroing strategy (Linus Torvalds) [12354 bytes]
Partial reads and writes (Larry McVoy; Linus Torvalds) [12604 bytes]
Patches (Al Viro; Kirill Korotaev; Linus Torvalds; Theodore Tso) [34010 bytes]
Patch tracking (Linus Torvalds) [19166 bytes]
Patents (Al Viro; Larry McVoy; Linus Torvalds; Theodore Tso) [14147 bytes]
PC clocks (H. Peter Anvin) [3857 bytes]
The penguin logo (Linus Torvalds) [1043 bytes]
Using pipes to send a packet stream (Linus Torvalds) [1395 bytes]
pivot_root() (Linus Torvalds) [3382 bytes]
I/O plugging (Jens Axboe; Linus Torvalds) [22911 bytes]
Pointer overlap (Linus Torvalds) [3848 bytes]
Pointer subtraction (Al Viro; Linus Torvalds) [4764 bytes]
Point-to-point links (Linus Torvalds) [4504 bytes]
POP instruction speed (Jeff Garzik; Linus Torvalds) [21275 bytes]
Priority inheritance (Linus Torvalds) [3952 bytes]
Process wakeup (Linus Torvalds) [2725 bytes]
/proc/self/fd (Theodore Tso) [2043 bytes]
ptrace and mmap (Linus Torvalds) [7146 bytes]
ptrace() self-attach (Linus Torvalds) [4480 bytes]
ptrace() and signals (Linus Torvalds) [17993 bytes]
put_user() (Linus Torvalds) [4292 bytes]
Quirks (Linus Torvalds) [6629 bytes]
RAID0 (Linus Torvalds) [8803 bytes]
Readahead (Linus Torvalds) [1903 bytes]
readdir() nonatomicity (Theodore Ts'o) [5534 bytes]
Recursive locks (Linus Torvalds) [8847 bytes]
Reference counting (Linus Torvalds) [4766 bytes]
Regression tracking (Linus Torvalds) [26622 bytes]
Reiser4 (Christoph Hellwig; Linus Torvalds; Theodore Ts'o; Al Viro) [26551 bytes]
Resource forks (Linus Torvalds; Theodore Y. Ts'o) [26100 bytes]
C99's 'restrict' keyword (Linus Torvalds) [3372 bytes]
Revision-control filesystem (Linus Torvalds) [1970 bytes]
RTLinux (Linus Torvalds) [10020 bytes]
rwlocks (Linus Torvalds) [14504 bytes]
The scheduler (Linus Torvalds) [7765 bytes]
SCSI ids (Linus Torvalds) [7915 bytes]
The SCSI layer (Theodore Tso) [11473 bytes]
Security bugs (Al Viro; Linus Torvalds; Theodore Tso) [36711 bytes]
Security mailing lists (Alan Cox; Linus Torvalds; Theodore Ts'o) [59846 bytes]
Security (Linus Torvalds; Theodore Tso) [37230 bytes]
select() (Linus Torvalds) [4180 bytes]
SELinux (Al Viro; Ingo Molnar; Linus Torvalds; Theodore Tso) [17087 bytes]
Semaphores (Linus Torvalds) [54756 bytes]
sendfile() (Linus Torvalds) [38139 bytes]
The serial port driver (Theodore Tso) [4737 bytes]
32-bit shifts (Linus Torvalds) [2540 bytes]
Signal-safe (Linus Torvalds) [1395 bytes]
Signals and system call restarting (Theodore Y. Ts'o) [2419 bytes]
signal_struct (Linus Torvalds) [2894 bytes]
Signed divisions (Al Viro; Linus Torvalds) [8195 bytes]
Signed pointers (Linus Torvalds) [1398 bytes]
Signed<->unsigned casts (Linus Torvalds) [3023 bytes]
The slab allocator (Linus Torvalds) [7349 bytes]
Small static binaries (Ulrich Drepper; Zack Weinberg) [6824 bytes]
SMP costs (Linus Torvalds) [2184 bytes]
socklen_t (Linus Torvalds) [1905 bytes]
Soft Update filesystems (Theodore Ts'o) [7906 bytes]
Software prefetching from memory (Linus Torvalds) [4011 bytes]
Software quality (Al Viro) [4574 bytes]
Sparse (Linus Torvalds; Al Viro) [34099 bytes]
Specs (Al Viro; Linus Torvalds; Theodore Ts'o) [14055 bytes]
Spinlocks (Ingo Molnar; Linus Torvalds; Paul E. McKenney) [59161 bytes]
splice() (Linus Torvalds) [35592 bytes]
Richard Stallman (Al Viro) [1266 bytes]
stat() sizes of pipes/sockets (Linus Torvalds) [1789 bytes]
CPU store buffers (Linus Torvalds) [8142 bytes]
strncpy() (Linus Torvalds) [1519 bytes]
Struct declarations (Linus Torvalds) [2683 bytes]
Struct initialization (Al Viro; Linus Torvalds) [13396 bytes]
Stupid mail clients (Linus Torvalds) [5129 bytes]
Sun (Linus Torvalds) [4940 bytes]
Suspend (Linus Torvalds; Theodore Tso) [16757 bytes]
Symbolic links and git (Linus Torvalds) [1437 bytes]
Symbol printing (Linus Torvalds) [4754 bytes]
Sysfs (Al Viro; Theodore Tso) [19319 bytes]
Syslog clogs (Linus Torvalds) [1436 bytes]
Hardware clock on localtime, and fsck (Martin Schwidefsky; Michal Schmidt; Theodore Tso) [8467 bytes]
Thread-synchronous signals (Linus Torvalds) [4482 bytes]
Timer wrapping-around in C (Johannes Stezenbach; Linus Torvalds) [8575 bytes]
TLAs (Linus Torvalds) [2938 bytes]
Tool bundling (Al Viro; Linus Torvalds) [16966 bytes]
Triple faults (Linus Torvalds) [1090 bytes]
TSC (Linus Torvalds) [4476 bytes]
tty access times (Linus Torvalds) [3767 bytes]
Tuning parameters (Linus Torvalds) [2271 bytes]
TXT (Theodore Tso) [10849 bytes]
Typedefs (Linus Torvalds) [14694 bytes]
Unsigned arithmetic (Linus Torvalds) [3232 bytes]
User / kernel splits (Linus Torvalds) [9634 bytes]
User pointers (Linus Torvalds) [2653 bytes]
User-space filesystems (Linus Torvalds) [10500 bytes]
User-space I/O (Linus Torvalds) [11647 bytes]
UTF-8 (H. Peter Anvin; Jamie Lokier; Linus Torvalds; Theodore Ts'o; Al Viro) [69577 bytes]
utrace (Linus Torvalds; Theodore Ts'o) [33682 bytes]
Vendor-driven (Linus Torvalds) [8492 bytes]
vmalloc() (Jens Axboe; Linus Torvalds; Theodore Ts'o) [10819 bytes]
VMAs (Linus Torvalds) [4351 bytes]
vm_dirty_ratio (Linus Torvalds) [7775 bytes]
Wakekill (Linus Torvalds) [16695 bytes]
work_on_cpu() (Linus Torvalds) [1627 bytes]
Write barriers (Linus Torvalds) [26514 bytes]
Write combining (Linus Torvalds) [2749 bytes]
write() error return (Linus Torvalds) [2777 bytes]
x86-64 (Linus Torvalds) [4881 bytes]
x86 rings (H. Peter Anvin; Linus Torvalds) [4518 bytes]
The x86 TLB (Linus Torvalds) [9941 bytes]
x86 versus other architectures (Linus Torvalds) [22123 bytes]
Xen (Linus Torvalds) [3920 bytes]
XFS (Al Viro) [1740 bytes]
Zero-copy (Linus Torvalds) [28652 bytes]
ZERO_PAGE (Linus Torvalds) [11084 bytes]
Zero as a special value (Linus Torvalds) [27396 bytes]
ZFS (Theodore Tso) [5759 bytes]

Katy – 68000 Linux on a Solderless Breadboard

www.bigmessowires.com - Comments

What does it take to build a little 68000-based protoboard computer, and get it running Linux? In my case, about three weeks of spare time, plenty of coffee, and a strong dose of stubborness. After banging my head against the wall with problems ranging from the inductance of pushbutton switches to memory leaks in the C standard library, it finally works! I’ve built several other DIY computer systems before, but never took their software beyond simple assembly language programs. Having a full-fledged multitasking OS running on this ugly pile of chips and wires is a thrill, and opens up all kinds of interesting new possibilities. I’ve named this plucky little machine 68 Katy.

 
Hardware

68-katy-protoboard-final

Here’s a look at the final version of the hardware. It took about a week to assemble and wire up all the parts on a solderless breadboard. The heart of the system is a Motorola 68008 CPU, a low-cost variant of the more common 68000, with fewer address pins and an 8-bit data bus. The CPU has 20 address pins, allowing for 1 MB of total address space. It’s paired with a 512K 8-bit SRAM, and a 512K Flash ROM (of which 480K is addressable – the remaining 32K is memory-mapped I/O devices).

The standard 68000 CPU has a 16-bit data bus, so it normally requires at least two 8-bit RAM chips and two 8-bit ROM chips. The 68008 requires fewer memory chips thanks to its 8-bit data bus, but the trade-off is that memory bandwidth is only half that of the 68000. Neither chip has any on-board cache, so half the memory bandwidth leads to roughly half the performance. My 68008 runs at 2 MHz (it was unstable when tested at 4 MHz), providing similar performance to a 1 MHz 68000. That’s pretty slow, even in comparison to 68000 systems from the early 1980’s, which were typically 8 MHz or faster.

An FT245 USB-to-FIFO module provides a communication link to another computer. On the external PC, it appears as a virtual serial port. Windows Hyperterm or another similar terminal program can be used to communicate with it, like an old VT100 terminal. On the 68 Katy side, the FT245 appears as a byte-wide I/O register mapped into the CPU’s address space. Reading from its address fetches the next incoming byte from the PC, and writing to the address sends a byte out to the PC. The FT245 has an internal 256-byte buffer, which helps smooth out the communication. When there’s an incoming byte waiting in the buffer, it triggers a CPU interrupt.

A 555 timer provides the only other interrupt source, generating a regular series of CPU interrupts at roughly 100 Hz. The initial version of the hardware had no timer interrupt, but I later discovered it was essential in order to get Linux working correctly.

The protoboard has eight LEDs for debugging, which are driven from a memory-mapped 74LS377 register. The rest of the protoboard is filled with assorted 7400 series parts and one PAL, which are used for address decoding, interrupt arbitration, and other basic glue logic.

Schematics? Forget it. Everything was built incrementally, one wire at a time, while staring at chip datasheets. It’s an organic creation.

 
Software

Once the hardware build was done, I began writing some simple test programs in 68K assembly language. Wichit Sirichote’s zBug monitor provided a good starting point for my own ROM-based monitor/bootloader. Using the monitor program, I was able to load other programs in binary or Motorola S-record format over the FT245 link, store them in RAM, and execute them. I was even able to get Lee Davison’s ehBASIC for 68000 working, which provided a few hours of fun.

One feature I could have added to the monitor program, but didn’t, was the ability to reprogram the Flash ROM. The ROM chip has a read/write input pin just like an SRAM, but writing to the Flash ROM is more complicated. The CPU needs to first write a magic sequence of bytes in order to unlock the ROM. Then it needs to write more magic bytes to tell the ROM which blocks to erase, followed by the new bytes to be written. Finally, it must poll the output of the ROM to learn when the erase and reprogram sequence is complete.

The monitor program could have updated itself, or any other data stored in ROM, by copying itself to RAM, then running from RAM while saving new data to Flash ROM. But I was lazy and never implemented that feature, so I had to physically pull the ROM chip from the protoboard and place it in an external EPROM programmer whenever I made a change – about 100 times over the course of the project. Ugh.

 
Linux

Inspired by a similar project, I decided that a simple monitor program and BASIC weren’t interesting enough, and I needed to run Linux on this hardware. It sounded interesting and exciting, but I really had no idea where to begin. I had plenty of experience as a Linux user (as well as other UNIX versions), but I knew nothing about how the kernel worked, or how to build it from source code, or to port it to new hardware. So the real adventure began there.

The first challenge was to learn how to build a Linux image for an existing machine. It seemed simple enough in theory – just download the source code from kernel.org or some other distribution tree, and compile it. Reality was more complicated, and there were many details that confused me, and build problems I was powerless to solve. It wasn’t easy, and I discussed the process in much more detail in this earlier post.

I chose to use uClinux, a Linux distribution designed for microcontrollers and other low-end hardware, particularly CPUs without an MMU and that can’t support virtual memory. Then I chose a very old version of uClinux, based on kernel 2.0.39, that dates all the way back to 2001! I configured it to disable nearly every single optional feature, including all networking support. This ancient code was my best hope for getting a Linux that would actually run in 512K of ROM and 512K of RAM.

Starting with the uClinux configuration for another 68000-based system, I updated the code to reflect the 68 Katy memory map, changed the system initialization code, and added a driver for the FT245. Describing those steps makes them sound simple, and they might have been for someone more experienced with Linux, but for me it was a challenge just to identify which files and functions needed to modified. Google wasn’t very helpful, since I was working with such an old version of the kernel, and the resources I found on building/porting Linux mostly weren’t applicable. I primarily relied on the Linux grep command to search through the thousands of kernel source files for strings of interest, then stared at the code until I could understand how it worked.

After about a week, I had something I was ready to test. And it worked, at least a little bit! It showed the first few lines of kernel output, but hung at “calibrating delay loop”. Aha, I needed a timer interrupt. Of course! I added a 555 timer and some extra interrupt logic, and was ready to try again.

The second attempt got further into the boot process, but failed to mount the memory-resident root filesystem. I was stumped for a while. After looking more carefully, I discovered that my linker script was mapping the root filesystem and BSS to the same address in RAM, and the earily initialization code was overwriting the filesystem with zeroes. And more fundamentally, I discovered that it wasn’t possible to fit all of Linux in 512K RAM, including the kernel code, static data, root filesystem, and dynamically allocated memory. Something had to be moved to ROM, or it was never going to work.

In the third attempt, I moved the root filesystem image to ROM, freeing up about 150K of RAM. And this kind of, almost worked! It booted, mounted the filesystem, and seemed to be working OK, but then suddenly it would land back at the monitor program prompt. Huh? I eventually tracked this one to the FT245 driver I’d written. I only implemented the minimal set of required driver functions, and the other optional functions were NULL entries in a function table somewhere. One of the functions I thought was optional proved to be required. When the kernel called it, it used a NULL function pointer, causing a jump to address 0, restarting my monitor program.

The fourth attempt was better. It spawned the init process, and ran the startup script, but died with out-of-memory errors before it completed. At the time, 68 Katy’s memory map was 256K ROM, 256K I/O devices, and 512K RAM. By shrinking the I/O space to 32K, I was able to increase the usable ROM to 480K, providing enough space to store the root filesystem image and the kernel code itself! This freed up another 251K of RAM.

The fifth attempt actually booted to a shell prompt! Now it was executing the kernel code directly from ROM. I was able to run a few commands, like ls and cat, but then the system would run out of memory and die. As I investigated, it looked like memory allocated from malloc() and do_mmap() was never beeing freed. Was this some kind of free list allocator I didn’t understand? No. It turns out I’d made a typo in a function called is_in_rom(), adding too many zeroes, causing the memory allocator to think all addresses were in ROM and so didn’t need to be freed. Then after fixing that, I discovered a small memory leak in the C library setenv() function. I never did solve that one, but instead just modified the programs that used it to avoid calling it.

My debugging method was primitive: lots of printk and printf statements sprinkled everywhere. Then pull the ROM chip, reprogram it in an external EPROM programmer, replace it in the protoboard, and try again.

The sixth attempt finally worked. Two weeks after beginning my experiments with Linux, I had a working system! Here’s a screenshot of the boot sequence:

linux-2.0.39-boot

Watch the video for more details. I’m using a shell called sash, which has a few dozen common shell commands (like ls and cat) built directly into it. The root filesystem in ROM is read-only, and a small read-write filesystem is created in a RAM disk. The system supports multitasking, so it can run an LED blinker program in the background while still working in the Linux shell. It even has vi, and Colossal Cave Adventure!

It was an interesting journey. The Linux kernel still seems big and unwiedly to me, but no longer seems so scary as it did initially. It’s just an especially big program, and most of its pieces aren’t too difficult to understand if you open up the relevant source files and start reading.

 
Memory Requirements

So how much memory does it require to run a super-minimal uClinux system, with an old 2.0 kernel? If you follow my example and put as much as possible in ROM, it needs about 343K of ROM and 312K of RAM, or just 628K of RAM if you’ve got a bootloader that can fill RAM from some external source. My 68 Katy system is slightly heavier than that due to including vi and Adventure, but not by much. Here’s the breakdown:

ROM

  • kernel code and read-only data (.text and .rodata segments) – 251K
  • kernel initialized static data (.data segment) – 27K
  • root filesystem – 189K

RAM

  • kernel static data (.data and .bss segments) – 84K
  • kernel dynamic allocations during boot-up – 104K
  • RAM disk – 64K
  • init and shell process allocations – 58K
  • stack and exception vectors – 2K

 
Problems

The kernel always measures the CPU at 0.81 bogomips, regardless of the clock crystal I use. The 555 timer interrupt is independent of the CPU clock, so with a faster clock the bogomips calculation should measure more executions of the busy loop per timer interrupt. I’m not sure why it doesn’t, but it means any real-time calculations will be off.

The display in vi acts weird. Some lines appear prefixed with a capital H, and stray Unicode characters appear here and there. At first I thought this was a hardware bug, and I’m still not certain it isn’t. But I think it’s probably an issue with the way my terminal program (Tera Term) handles the ANSI escape sequences sent by vi. I tried all the different terminal settings available in Tera Term, and also tried a different terminal program, all with the same result.

 
What’s Next?

This 68008 system on a protoboard was intended to be only an experiment and proof-of-concept for the real 68 Katy, which I had planned to build on a custom PCB with a full 68000 CPU, a CPLD for glue logic, more RAM, an SD card, and ethernet. But this experiment was perhaps a bit too successful, and now I’m wondering if it really makes sense to go to the effort of building the “real” system if it’s going to be essentially the same thing, only faster. Of course the SD card and ethernet will add some interesting new elements, so maybe it’s fine. I probably need to sleep on the question for a few days.

One way of adding more spice to the next iteration of 68 Katy would be to include video output, so it could directly drive a monitor instead of being controlled through a serial terminal. I’ve done that once before, with BMOW 1, which had VGA output. It mostly worked, although the arbitration for video memory between the display hardware and the CPU was clunky and produced visible display artifacts. To take things further, I could even aim for DVI or HDMI video output, since VGA is a slowly dying standard.

The smart move is probably to stick with my original plan. Lots of extra features are cool, but also have a way of killing a project. I’d rather have something with 10 features and that works, than something with 20 features that I never finished or that collapsed under the weight of its complexity. But until then, excuse me while I go play some more Colossal Cave…

 
Files
The source code for my 68 Katy port of uClinux is available for download, as well as the toolchain I used to build it, the monitor/bootloader source, and a preconfigured VirtualBox machine image of Ubuntu 12.04 to host it all. Grab the files here. Have fun!

 

New blood test for stroke combines blood-based biomarkers with a clinical score

medicalxpress.com - Comments

blood test Credit: Pixabay/CC0 Public Domain

Stroke is the leading cause of disability worldwide and the second leading cause of death, but the right early intervention can prevent severe consequences. A new study led by investigators from Brigham and Women's Hospital and collaborators describes how the team developed a new test by combining blood-based biomarkers with a clinical score to identify patients experiencing large vessel occlusion (LVO) stroke with high accuracy.

The results are published in the journal Stroke: Vascular and Interventional Neurology.

"We have developed a game-changing, accessible tool that could help ensure that more people suffering from stroke are in the right place at the right time to receive critical, life-restoring care," said senior author Joshua Bernstock, MD, Ph.D., MPH, a clinical fellow in the Department of Neurosurgery at Brigham and Women's Hospital.

Most strokes are ischemic, in which blood flow to the brain is obstructed. LVO strokes are an aggressive type of ischemic stroke that occurs when an obstruction occurs in a major artery in the brain. When blood supply to the brain is compromised, the lack of oxygen and nutrients causes brain cells to die within minutes. LVO strokes are major medical emergencies and require the swift treatment with mechanical thrombectomy, a surgical procedure that retrieves the blockage.

"Mechanical thrombectomy has allowed people that otherwise would have died or become significantly disabled be completely restored, as if their stroke never happened," said Bernstock. "The earlier this intervention is enacted, the better the patient's outcome is going to be. This exciting new technology has the potential to allow more people globally to get this treatment faster."

The research team had previously targeted two specific proteins found in capillary blood, one called glial fibrillary acidic protein (GFAP), which is also associated with brain bleeds and traumatic brain injury; and one called D-dimer.

In this study, they demonstrated that the levels of these blood-based biomarkers combined with field assessment stroke triage for emergency destination (FAST-ED) scores could identify LVO ischemic strokes while ruling out other conditions such as bleeding in the brain. Brain bleeds cause similar symptoms to LVO stroke, making them hard to distinguish from one another in the field, yet treatment for each is vastly different.

In this prospective, observational diagnostic accuracy study, the researchers looked at data from a cohort of 323 patients coded for stroke in Florida between May 2021 and August 2022. They found that combining the levels of the biomarkers GFAP and D-dimer with FAST-ED data less than six hours from the onset of symptoms allowed the test to detect LVO strokes with 93% specificity and 81% sensitivity. Other findings included that the test ruled out all patients with brain bleeds, signaling that the technology may ultimately also be employed to detect intracerebral hemorrhage in the field.

Bernstock's team also sees promising potential future use of this accessible diagnostic tool in low- and middle-income countries, where advanced imaging is not always available. It might also be useful in assessing patients with traumatic brain injuries. Next, they will carry out another prospective trial to measure the test's performance when used in an ambulance. They have also designed an interventional trial that leverages the technology to expedite the triage of stroke patients by having them bypass standard imaging and move directly to intervention.

"In stroke care, time is brain," Bernstock said. "The sooner a patient is put on the right care pathway, the better they are going to do. Whether that means ruling out bleeds or ruling in something that needs an intervention, being able to do this in a prehospital setting with the technology that we built is going to be truly transformative."

Additional authors include Yasir Durrani, Jakob V. E. Gerstl, Danielle Murphy, Ashley Harris, Imane Saali, Toby Gropen, Shashank Shekhar, Ari D. Kappel, Nirav J. Patel, Rose Du, Rodolfo E. Alcedo Guardia, Juan C. Vicenty-Padilla, Adam A. Dmytriw, Vitor Mendes Pereira, Saef Izzy, Allauddin Khan, Mohammed A. Aziz-Sultan, David S. Liebeskind, Jason M. Davies, Adnan H. Siddiqui, and Edoardo Gaude.

More information: Durrani Y, Prospective validation of GFAP, D-dimer and clinical scales for acute large vessel occlusion ischemic stroke detection, Stroke Vascular and Interventional Neurology (2024). DOI: 10.1161/SVIN.123.001304

Citation: New blood test for stroke detection combines blood-based biomarkers with a clinical score (2024, May 17) retrieved 19 May 2024 from https://medicalxpress.com/news/2024-05-blood-combines-based-biomarkers-clinical.html

This document is subject to copyright. Apart from any fair dealing for the purpose of private study or research, no part may be reproduced without the written permission. The content is provided for information purposes only.

Riven

www.filfre.net - Comments

Robyn and Rand Miller.

Sometimes success smacks you right in the face. More often, it sneaks up on you from behind.

In September of 1993, the brothers Rand and Robyn Miller and the few other employees of Cyan, Inc., were prototypical starving artists, living on “rice and beans and government cheese.” That month they saw Brøderbund publish their esoteric Apple Macintosh puzzle game Myst, which they and everyone else regarded as a niche product for a niche platform. There would go another year before it became abundantly clear that Myst, now available in a version for Microsoft Windows as well as for the Mac, was a genuine mass-market hit. It would turn into the gift that kept on giving, a game with more legs than your average millipede. It wouldn’t enjoy its best single month until December of 1996, when it would set a record for the most copies one game had ever sold in one month.

All of this — not just the sales figures themselves but the dozens of awards, the write-ups in glossy magazines like Rolling Stone and Newsweek, the fawningly overwritten profiles in Wired, the comparisons with Steven Spielberg’s Jurassic Park and Michael Jackson’s Thriller — happened just gradually enough that it seemed almost natural. Almost natural. “It took a while for it to hit me that millions of people were buying this game,” says Robyn Miller. “The most I could really wrap my head around would be to go to a huge concert and see all of the people there and think, ‘Okay, this is not even a portion of the people who are playing Myst.'”

The Miller brothers could have retired and lived very comfortably for the rest of their lives on the fortune they earned from Myst. They didn’t choose this path. “We took salaries that were fairly modest and just put the company’s money back into [a] new project,” says Rand.

Brøderbund was more than eager for a sequel to Myst, something that many far smaller hits than it got as a matter of course within a year. But the Miller brothers refused to be hurried, and did not need to be, a rare luxury indeed in their industry. Although they enjoyed a very good relationship with Brøderbund, whose marketing acumen had been essential to getting the Myst ball rolling, they did not wish to be beholden to their publisher in any way. Rather than accepting the traditional publisher advance, they decided that they would fund the sequel entirely on their own out of the royalties of the first game. This meant that, as Myst blew up bigger and bigger, their ambitions for the game they intended to call Riven were inflated in tandem. They refused to give Brøderbund a firm release date; it will be done when it’s done, they said. They took to talking about Myst as their Hobbit, Riven as their Lord of the Rings. It had taken J.R.R. Tolkien seventeen years to bridge the gap between his children’s adventure story and the most important fantasy epic in modern literary history. Surely Brøderbund could accept having to wait just a few years for Riven, especially with the sales figures Myst was still putting up.

Cyan’s digs reflected their rising status. They hadn’t even had a proper office when they were making Myst; everybody worked out of their separate homes in and around Spokane, Washington, sharing their output with one another using the “car net”: put it on a disk, get into your car, and drive it over to the other person. In the immediate aftermath of Myst’s release and promising early sales, they all piled into a drafty, unheated garage owned by their sound specialist Chris Brandkamp. Then, as the sales numbers continued to tick upward, they moved into an anonymous-looking former Comfort World Mattress storefront. Finally, in January of 1995, they broke ground on a grandiosely named “Cyan World Headquarters,” whose real-world architecture was to be modeled on the virtual architecture of Myst and Riven. While they were waiting for that building to be completed — the construction would take eighteen months — they junked the consumer-grade Macs which had slowly and laboriously done all of the 3D modeling necessary to create Myst’s environments in favor of Silicon Graphics workstations that cost $40,000 a pop.


Cyan breaks ground on their new “world headquarters.”

The completed building looked very much apiece with their games, both outside…

…and inside.

The machines that made Riven. Its imagery was rendered using $1 million worth of Silicon Graphics hardware: a dozen or so workstations connected to these four high-end servers that did the grunt work of the ray-tracing. It was a far cry from Myst, which had been made with ordinary consumer-grade Macs running off-the-shelf software.

And the people who made Riven


There were attempts to drum up controversies in the press, especially after Riven missed a tentative Christmas 1996 target date which Brøderbund had (prematurely) announced, a delay that caused the publisher’s stock price to drop by 25 percent. The journalists who always seemed to be hovering around the perimeter of Cyan’s offices claimed to sniff trouble in the air, an aroma of overstretched budgets and creative tensions. But, although there were certainly arguments — what project of this magnitude doesn’t cause arguments? — there was in truth no juicy decadence or discord going on at Cyan. The Miller brothers, sons of a preacher and still devout Christians, never lost their Heartland groundedness. They never let their fluke success go to their heads in the way of, say, the minds behind Trilobyte of The 7th Guest fame, were never even seriously tempted to move their operation to some more glamorous city than Spokane. For them, it was all about the work. And luckily for them, plenty of people were more than willing to move to Spokane for a chance to work at The House That Myst Built, which by the end of 1995 had replaced Trilobyte as the most feted single games studio in the mainstream American press, the necessary contrast to all those other unscrupulous operators who were filling their games and the minds of the nation’s youth with indiscriminate sex and violence.

The most important of all the people who were suddenly willing to come to Spokane would prove to be Richard Vander Wende, a former Disney production designer — his fingerprints were all over the recent film Aladdin — who first bumped into the Miller brothers at a Digital World Expo in Los Angeles. Wende’s conceptual contribution to Riven would be as massive as that of either of the Miller brothers, such that he would be given a richly deserved co-equal billing with them at the very top of the credits listing.

Richard Vander Wende.

Needless to say, though, there were many others who contributed as well. By the time Cyan moved into their new world headquarters in the summer of 1996, more than twenty people were actively working on Riven every day. The sequel would wind up costing ten times to fifteen times as much to make as its predecessor, filling five CDs to Myst’s lone silver platter.

Given the Millers’ artistic temperament and given the rare privilege they enjoyed of being able to make exactly the game they wished to make, one might be tempted to assume that Riven was to be some radical departure from what had come before. In reality, though, this was not the case at all. Riven was to be Myst, only more so; call it Myst perfected. Once again you would be left to wander around inside a beautiful pre-rendered 3D environment, which you would view from a first-person perspective. And once again you would be expected to solve intricate puzzles there — or not, as you chose.

Cyan had long since realized that players of Myst broke down into two broad categories. There were those they called the gamers, who engaged seriously with it as a series of logical challenges to be overcome through research, experimentation, and deduction. And then there was the other group of players — a far, far larger one, if we’re being honest — whom Cyan called the tourists, who just wanted to poke around a little inside the virtual world and take in some of the sights and sounds. These were folks like the residents of a retirement home who wrote to Cyan to say that they had been playing and enjoying Myst for two years and two months, and wanted to hear if the rumors that there were locations to explore beyond the first island — an island which constitutes about 20 percent of the full game — were in fact true.

Riven was meant to cater to both groups, by giving the gamers a much deeper, richer, more complex tapestry of puzzles to unravel, whilst simultaneously being kept as deliberately “open” as possible in terms of its geography, so that you could see most of its locations without ever having to solve a single conundrum. “The two complaints about Myst,” said Rand Miller, “were that it was too hard and too easy. We’re trying to make Riven better for both kinds of players.” Whereas Myst allowed you to visit four separate “ages” — basically, alternative dimensions — after solving those early puzzles which had so stymied the retirees, Riven was to take place all in the same dimension, on a single archipelago of five islands. You would be able to travel between the islands right from the start, using vehicles whose operation should be quite straightforward even for the most puzzle-averse players. If all you wanted to do was wander around the world of Riven, it would give you a lot more spaces in which to do so than Myst.

Of course, while the world of Riven was slowly coming together, the real world wasn’t sitting still. Myst had been followed by an inevitable flood of “Myst clones” from other publishers and studios, which, in lieu of a proper sequel from Cyan, did their best to pick up the slack by offering up their own deserted, 3D-rendered environments to explore. Few of them were more than modestly successful; Activision’s Zork Nemesis, which may have done the best of them all, sold about 450,000 copies, an order of magnitude and a half less than the final numbers that Myst would put up. Meanwhile the genre of adventure games in general had peaked in the immediate aftermath of Myst and would be well into an increasingly precipitous decline by the time Riven shipped in October of 1997. The Last Express, the only other adventure that Brøderbund published that year, stiffed badly in the spring, despite sporting prominently on its box the name of Jordan Mechner, one of the few videogame auteurs with a reputation to rival that of the Miller brothers.

Yet Cyan’s own games still seemed weirdly proof against the marketplace pressures that were driving so many other game makers in the direction of real-time strategy and first-person shooters. In June of 1997, the nearly four-year-old Myst was propelled back to the top of the sales charts by the excitement over the approaching debut of Riven. And when it did appear, Riven didn’t disappoint the bean counters. It and Myst tag-teamed one another in the top two chart positions right through the Christmas buying season. Myst would return to number one a few more times in the course of 1998, while an entire industry continued to scratch its collective head, wondering why this particular game — a game that was now approaching its fifth birthday, making it roughly as aged as the plays of Shakespeare as the industry reckoned time — should continue to sell in such numbers. Even today, it’s hard to say precisely why Myst just kept selling and selling, defying all the usual gravities of its market. It seems that non-violent, non-hardcore gaming simply needed a standard bearer, and so it found one for itself.

Riven wasn’t quite as successful as Myst, but this doesn’t mean it didn’t do very well indeed by all of the standard metrics. Its biggest failing in comparison to its older sibling was ironically its very cutting-edge nature; whereas just about any computer that was capable of running other everyday software could run Myst by 1997, you needed a fairly recent, powerful machine to run Riven. Despite this, and despite the usual skepticism from the hardcore-gaming press — “With its familiar, lever-yanking gameplay, Riven emerges as the ultimate Myst clone,” scoffed Computer Gaming World magazine — Riven’s sales surpassed 1 million units in its first year, numbers of which any other adventure game could scarcely have dreamed.

Riven was a huge hit by any conventional standard, but it didn’t have the legs of Myst. Already for long stretches during 1998, it was once again being comfortably outsold by Myst. Lifetime retail sales of around 1.5 million strike me as the most likely figure — still more than enough to place Riven in the upper echelon of late 1990s computer games.

Fans and boosters of the genre naturally wanted to see a broader trend in Riven’s sales, a proof that adventures in general could still bring home the bacon with the best of them. The hard truth that the games of Cyan were always uniquely uncoupled from what was going on around them was never harder to accept than in this case. In the end, though, Riven would have no impact whatsoever on the overall trajectory of the adventure genre.


Because Riven is a sequel in such a pure sense — a game that aims to do exactly what its predecessor did, only bigger and better — your reaction to it is doomed to be dictated to a large extent by your reaction to said predecessor. It’s almost impossible for me to imagine anyone liking or loving Riven who didn’t at least like Myst.

The defining quality of both games is their thoroughgoing sense of restraint. When Myst first started to attract sales and attention, naysayers saw its minimalism through the lens of technical affordance, or rather the Miller brothers’ lack thereof: having only off-the-shelf middleware like HyperCard to work with, lacking the skill set that might have let them create better tools of their own, they just had to do the best they could with what they had. In this reading, Myst‘s static world, its almost nonexistent user interface, its lack of even such niceties as a player inventory, stemmed not so much from aesthetic intent as from the fact that it had been created with a hypertext editor that had never been meant for making games. The alternative reading is that the Miller brothers were among the few game developers who knew the value of restraint from the start, that they were by nature and inclination minimalists in an industry inclined to maximalism in all things, and this quality was their greatest strength rather than a weakness. The truth probably lies somewhere between the two extremes, as it usually does. Regardless, there’s no denying that the brothers leaned hard into the same spirit of minimalism that had defined Myst when the time came to make Riven, even though they were now no longer technologically constrained into doing so. One camp reads this as a colossal failure of vision; the other reads it as merely staying true to the unique vision that had gotten them this far.

While I don’t want to plant myself too firmly in either corner, I must say that I am surprised by some of the things that Cyan didn’t do with twice the time and ten or fifteen times the budget. The fact that Riven still relies on static, pre-rendered scenery and node-based movement isn’t the source of my surprise; that compromise was necessary in order to achieve the visual fidelity that Cyan demanded. I’m rather surprised by how little Cyan innovated even within that basic framework. Well before Riven appeared, the makers of other Myst successors had begun to experiment with ways of creating a slightly more fluid, natural-feeling experience. Zork Nemesis, for example, stores each of its nodes as a 360-degree panorama instead of a set of fixed views, letting you smoothly turn in place through a complete circle. Riven, by contrast, confines its innovations in this area to displaying a little transition animation as you rotate between its rigidly fixed views. As a result, switching from view to view does become a little less jarring than it is in Myst, but the approach is far from even the Myst-clone state of the art.

Cyan was likewise disinterested in pursuing other solutions that would have been even easier to implement than panning rotation, but that could have made their game less awkward to play. The extent of your rotation when you click on the left or right side of the screen remains inconsistent, just as it was in Myst; sometimes it’s 90 degrees, sometimes it’s less or more. This can make simple navigation much more confusing than it needs to be, introducing a layer of fake difficulty — i.e., difficulties that you would not have if you were really in this world — which seems at odd with Cyan’s stated determination to create as immersive an experience as possible. Even a compass with which to tell which way you’re facing at any given time would have helped enormously, but no such concessions to player convenience are to hand.

Again, these are solutions that the other makers of Myst clones — not a group overly celebrated for its spirit of innovation — had long since deployed. Cyan was always a strangely self-contained entity, showing little awareness of what others were doing around them, making a virtue of their complete ignorance of the competition. In cases like these, it was perhaps not so much a virtue as a failure of simple due diligence. Building upon the work of others is the way that gaming as a whole progresses.

When it comes to storytelling as well, Riven’s differences from Myst are more a matter of execution than kind. As in Myst, there is very little story at all here, if by that we mean a foreground plot driving things along. A brief bit of exposition at the beginning picks up right where Myst ended, providing an excuse for dumping you into another open-ended environment. Whereas Myst took place entirely in deserted ages, here you’re ostensibly surrounded by the Rivenese, the vaguely Native-American-like inhabitants of the archipelago. Rather conveniently for Cyan, however, the Rivenese are terrified of strangers, and scurry away into hiding whenever you enter a scene. The few named characters you meet, including the principal villain, are likewise forever just leaving when you come upon them, or showing up, giving speeches, and then going away again before you can interact with them. By 1997, this sort of thing was feeling more tired than clever.

Rand Miller, returning in the role of the patriarch Atrus from Myst, gives you your marching orders and sends you on your way in the introductory movie. Riven makes more extensive use of such scenes involving real actors than Myst, but it’s done well, and never overdone. The end result is about as un-cheesy as these techniques can possibly look to modern eyes.

The real story, in both Myst and Riven, is the backstory that caused these spaces to become the places they are, a backstory which you uncover as you explore them. And in this area, I’m happy to say, Riven actually does outdo its predecessor. Almost everything there is to find out about how the ages of Myst became as they are is conveyed in one astonishingly clumsy infodump, a set of books which you find in a library on that first island after solving the first couple of puzzles. These stop your progress dead for an hour or so as you read through them, after which you’re back to exploring, never to be troubled by much of any exposition again.

By the time of Riven, however, the Miller brothers had learned about the existence of something called dramatic pacing. Here, too, most of the real story comes in the form of books and journals, but these are scattered around the islands, providing an enticement to solve puzzles in order to acquire and read them. The Myst “universe” grew considerably in depth and coherency between Myst and Riven, thanks to a trilogy of novels written by the British science-fiction author David Wingrove in close collaboration with the Miller brothers during that interim. In Riven, then, you get some of the same sense that you get in The Lord of the Rings, that you are only scraping the surface of a world that goes much deeper than its foreground sights and sounds. “The Lord of the Rings is so satisfying because of the details,” said Rand Miller at the time. “You get the feeling that the world you’re reading about is real. Different but real. That’s how we go about designing.” Like Tolkien, the Miller brothers went so far as to make up the beginnings at least of a coherent language for their land’s inhabitants. This sense of established lore, combined with the improved pacing and better writing, makes Riven’s backstory more compelling than that of Myst, makes uncovering more of it feel like a worthwhile goal in itself. Instead of providing a mere excuse for the gameplay, as in Myst, Riven’s backstory comes to fuel its gameplay to a large extent.

And this starts to take us into the territory of the first of the two things that Riven does really, really well, does so well in fact that you might just be willing to discount all of the failings I’ve been belaboring up to this point. The archipelago is a truly intriguing, even awe-inspiring place to explore, thank not just to the cutting-edge 3D-rendering technology that was used to bring it to life, but — and even more so — the thought that went into the place.

Riven makes its priorities clear from the beginning, when it asks you to set up your screen and your speakers to provide the immersive audiovisual experience it intends for you to have.

The adjective “surreal” seems unavoidable when discussing Myst, so much so that Brøderbund built it right into their advertising tagline. (“The Surrealistic Adventure That Will Become Your World.”) Looking back on it now, though, I realize that the surrealism of Myst was as much a product of process as intention. The 3D-modeling software that was used to create the scenery of Myst couldn’t render genuinely realistic scenes; everything it churned out was too geometrical, too stiff, too uniform in color to look in any sense real. The result was surrealism, that forlorn, otherworldly, even vaguely disturbing stripe of beauty that became the hallmark of Myst and its many imitators.

But I would not call Riven surreal. The improved technology that enabled it, on both the rendering side — meaning all those Silicon Graphics servers and workstations, with their complex ray-tracing algorithms — and the consumer-facing side — meaning the latest home computers, with their capability of displaying millions of nuanced shades of color onscreen at once — led to a more believable world. The key to it all is in the textures, the patterns that are overlaid onto the frame of a 3D model in lieu of blocks of solid color to make it look like a real object made out of wood, metal, or dirt. Cyan traveled to Santa Fe, New Mexico, to capture thousands of textures. The same visual qualities that led to that state being dubbed the “Land of Enchantment” and drew artists like Georgia O’Keeffe to its high deserts suffuses the game, from the pueblo walls of the Rivenese homes to the pebbly cliff-side paths, from an old iron tower rusting in the sun to the ragged vegetation huddling around it. You can almost feel the sun on your back and the sweat on your skin.

My wife and I are inveterate hikers these days, planning most of our holidays around where we can get out and walk. Riven made me want to climb through the screen and roam its landscapes for myself. Myst has its charms, but they are nothing like this. When I compare the two games, I think about what a revelation the battered, weathered world of Tatooine was when Star Wars hit cinemas in 1977, how at odds it was with the antiseptic sleekness of the science-fiction films that preceded it. Riven is almost as much of a revelation when set beside Myst and its many clones.



The visuals both feed and are fed by the backstory and the world-building. The islands are replete with little details that have nothing to do with solving the game, that exist simply as natural, necessary parts of this place you’re exploring. In a perceptive video essay, YouTube creator VZedshows notes how “the lived-in world of Riven lets us look at a house and say, ‘Okay, that’s a house.’ And that’s it. A totally different thought than seeing a log cabin on Myst Island and saying, ‘Okay, that’s a house. But what is it for?’ The puzzles in Riven melt into the world around them.”

Which brings us neatly to the other thing that Riven does remarkably well, the one aimed at the gamers rather than the tourists. Quite simply, Riven is one of the most elegantly sophisticated puzzle games ever created. This facet of it is not for everyone. (I’m not even sure it’s for me, about which more in a moment.) But it does what it sets out to do uncompromisingly well. Riven is a puzzle game that doesn’t feel like a puzzle game. It rather feels like you really have been dropped onto this archipelago, with its foreign civilization and all of its foreign artifacts, and then left to your own devices to make sense of it all.

Many of Riven’s puzzles are as much anthropological as mechanical. For example, you have to learn to translate the different symbols of a foreign number system.

This is undoubtedly more realistic than the ages of Myst, whose puzzles stand out from their environs so plainly that they might as well be circled with a bright red Sharpie. But does it lead to a better game? As usual, the answer is in the eye of the beholder. Ironically, almost everything that can be said about Riven’s puzzles can be cast as either a positive or a negative. If you’re looking for an adventure game that’s nails-hard and yet scrupulously fair — a combination that’s rarer than it ought to be — Riven will not disappoint you. If not, however, it will put you right off just as soon as you grow bored with idle wandering and begin to ask yourself what the game expects you to actually be doing. Myst was widely perceived in the 1990s as being more difficult than it really was; Riven, by contrast, well and truly earns its reputation.

Each of Myst’s ages is a little game unto itself when it comes to its puzzles; you never need to use tools or information from one age to overcome a problem in another one. For better or for worse, Riven is not like that — not at all. Puzzles and clues are scattered willy-nilly all over the five islands; you might be expected to connect a symbol you’re looking at now to a gadget you last poked at hours and hours ago. Careful, copious note-taking is the only practical way to proceed. I daresay you might end up spending more time poring over your real-world journal, looking for ways to combine and thereby to make sense of the data therein, than you do looking at the monitor screen. Because most of the geography is open to you from the very beginning — this is arguably Riven’s one real concession to the needs of the marketplace, being the one that allows it to cater to the tourists as well as the gamers — there isn’t the gated progress you get in so many other puzzly adventure games, with new areas and new problems being introduced gradually as you solve the earlier ones. No, Riven throws it all at you from the start, in one big lump. You just have to keep plugging away at it when even your apparently successful deductions don’t seem to be yielding much in the way of concrete rewards, trusting that it will all come together in one big whoosh at the end.

All of which is to say that Riven is a slow game, the polar opposite of the instant gratification that defines the videogame medium in the eyes of so many. There are few shortcuts for moving through its sprawling, fragmented geography — something you’ll need to do a lot of, thanks to its refusal to contain its puzzles within smaller areas as Myst does. Just double-checking some observation you think you made earlier or confirming that some effect took place as expected represents a significant investment in time. Back in the day, when everyone was playing directly from CD, Riven was even slower than it is today, requiring you to swap discs every time you traveled to a different island. In his vintage 1997 review, Andrew Plotkin — a fellow who is without a doubt much, much smarter than I am, at least when it comes to stuff like this — said that he was able to solve Riven in about twenty hours, using just one hint. It will probably take more mortal intelligences some multiple of one or both of those figures.

Your reaction to Riven when approached in “gamer” mode will depend on whether you think this kind of intensive intellectual challenge is fun or not, as well as whether you have the excess intellectual and temporal bandwidth in your current life to go all-in on such a major undertaking. I must sheepishly confess that my answer to the first question is more prevaricating than definitive, while my answer to the second one is a pretty solid no. In the abstract, I do understand the appeal of what Riven is offering, understand how awesome it must feel to put all of these disparate pieces together without help. Nevertheless, when I approached the game for this article, I couldn’t quite find the motivation to persevere down that road. Riven wants you to work a little harder for your fun than the current version of myself is willing to do. I don’t futz around with my notebook too long before I start looking out the window and thinking about how nice it would be to take a walk in real nature. I take enough notes doing research for the articles I write; I’m not sure I want to do so much research inside a game.

Prompted partially by my experience with Riven, I’ve been musing a fair amount lately about the way we receive games, and especially how the commentary you read on this site and others similar to it can be out of step with the way the games in question existed for their players in their heyday. I’m subject to the tyranny of my editorial calendar, to the need to just finish things, one way or another, and move on. Riven is not well-suited to such a mindset. In my travels around the Internet, I’ve noticed that those who remember the game most fondly often took months or years to finish it, or never finished it at all. It existed for them as a tempting curiosity, to be picked up from time to time and poked at, just to see if a little more progress was possible here or there, or whether the brainstorm that came to them unbidden while driving home from work that day might bear some sort of fruit. It’s an open question whether even folks who don’t have an editorial schedule to keep can recapture that mindset here and now, in the third decade (!) of the 21st century, when more entertainment of every conceivable type than any of us could possibly consume in a lifetime is constantly luring us away from any such hard nut as Riven. As of this writing, Cyan is preparing a remake of Riven. It will be interesting to see what concessions, if any, they chose to make to our new reality.

Even in the late 1990s, there was the palpable sense that Riven represented the end of an era, that even Cyan would not be able to catch lightning in a bottle a third time with yet another cerebral, contemplative, zeitgeist-stamping single-player puzzle game. Both Richard Vander Wende and Robyn Miller quit the company as soon as the obligatory rounds of promotional interviews had been completed, leaving the Myst franchise’s future solely in the hands of Rand Miller. Robyn’s stated reason for departing brings to the fore some of the frustrations I have with Cyan’s work. He said that he was most interested in telling stories, and had concluded that computer games just weren’t any good at that: “I felt like, you know what? It’s not working. This whole story thing is not happening, and one of the reasons it’s not happening is because of the medium. It’s not what this medium is good at.” So, he said, he wanted to work in film instead.

The obvious response is that Cyan had never actually tried to tell an engaging foreground story, had rather been content to leave you always picking up the breadcrumbs of backstory. Cyan’s stubborn conservatism in terms of form and their slightly snooty insistence on living in their own hermetically sealed bubble, blissfully unaware of the innovations going on around them in their industry in both storytelling and other aspects of game making, strike me as this unquestionably talented group’s least attractive qualities by far. When asked once what his favorite games were, Richard Vander Wende said he didn’t have any: “Robyn and I are not really interested in games of any kind. We’re more interested in building worlds. To us, Myst and Riven are not ‘games’ at all.” Such scare-quoted condescension does no one any favors.

Then again, that’s only one way of looking at it. Another way is to recognize that Riven is exactly the game — okay, if you like, the world — that its creators wanted to make. It’s worth acknowledging, even celebrating, as the brave artistic statement it is. Love it or hate it, Riven knows what it wants to be, and succeeds in being exactly that — no more, no less. Rather than The Lord of the Rings, call it the Ulysses of gaming: a daunting creation by any standard, but one that can be very rewarding to those willing and able to meet it where it lives. That a game like this outsold dozens of its more visceral, immediate rivals on the store shelves of the late 1990s is surely one of the wonders of the age.



Did you enjoy this article? If so, please think about pitching in to help me make many more like it. You can pledge any amount you like.


Sources: The books The Secret History of Mac Gaming (Expanded Edition) by Richard Moss, From Myst to Riven: The Creations & Inspirations by Richard Kadrey, and Riven: The Sequel to Myst: The Official Strategy Guide by Rick Barba; Computer Gaming World of January 1998; Retro Gamer 208; Wired of September 1997; Game Developer of March 1998. Plus the “making of” documentary that was included on the original Riven CDs. The sales figures for Zork Nemesis come from the Jordan Mechner archive at the Strong Museum of Play.

Online sources include GameSpot’s old preview of Riven, Salon’s profile of the Miller brothers on the occasion of Robyn’s departure from Cyan, VZedshows’s video essay on Myst and Riven, and Andrew Plotkin’s old review of Riven.

The original version of Riven is currently available as a digital purchase on GOG.com. As noted in the article above, a remake is in the works at Cyan.

 

Is artificial consciousness achievable? Lessons from the human brain

arxiv.org - Comments

Abstract:We here analyse the question of developing artificial consciousness from an evolutionary perspective, taking the evolution of the human brain and its relation with consciousness as a reference model. This kind of analysis reveals several structural and functional features of the human brain that appear to be key for reaching human-like complex conscious experience and that current research on Artificial Intelligence (AI) should take into account in its attempt to develop systems capable of conscious processing. We argue that, even if AI is limited in its ability to emulate human consciousness for both intrinsic (structural and architectural) and extrinsic (related to the current stage of scientific and technological knowledge) reasons, taking inspiration from those characteristics of the brain that make conscious processing possible and/or modulate it, is a potentially promising strategy towards developing conscious AI. Also, it is theoretically possible that AI research can develop partial or potentially alternative forms of consciousness that is qualitatively different from the human, and that may be either more or less sophisticated depending on the perspectives. Therefore, we recommend neuroscience-inspired caution in talking about artificial consciousness: since the use of the same word consciousness for humans and AI becomes ambiguous and potentially misleading, we propose to clearly specify what is common and what differs in AI conscious processing from full human conscious experience.

Mathematicians and the Selection Task (2004)

eric.ed.gov - Comments

Learning to think logically and present ideas in a logical fashion has always been considered a central part of becoming a mathematician. In this paper we compare the performance of three groups: mathematics undergraduates, mathematics staff and history undergraduates (representative of a "general population"). These groups were asked to solve Wason's selection task, a seemingly straightforward logical problem. Given the assumption that logic plays a major role in mathematics, the results were surprising: less than a third of students and less than half of staff gave the correct answer. Moreover, mathematicians seem to make different mistakes from the most common mistake noted in the literature. The implications of these results for our understanding of mathematical thought are discussed with reference to the role of error checking. [For complete proceedings, see ED489538.]

International Group for the Psychology of Mathematics Education, 35 Aandwind Street, Kirstenhof, Cape Town, 7945, South Africa. Web site: http://igpme.org.

Show HN: Open-source GeForce NOW alternative with Stadia's social features

github.com - Comments

[Experimental] Open-source GeForce NOW alternative with Stadia's social features

License

Additional navigation options

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Footer

You can’t perform that action at this time.

Michelle's List: A free, anonymous landlord review site

www.michelleslist.com - Comments

"Overall liked living here, our landlord was great, we stayed for about 6 years in the middle unit, had some great neighbors, and some just OK neighbors. The apartment itself was a good size, good price, great location. Would certainly recommend it!"

Mon May 06 2024

Mortgages are a manufactured product (2022)

www.bitsaboutmoney.com - Comments

Why is it so hard for entrepreneurs to get mortgages? Why did the address I send my payment to change? Why don’t most banks own mortgages anymore? Why is there a thriving economy of small specialist lenders locally who only do mortgages? Why is a 30-year fixed rate mortgage available at all?

Welcome to the wild and wooly world for mortgages in the United States: the world’s most important manufactured product that virtually no users understand. For starters, virtually no one outside of the value chain considers a mortgage a manufactured product at all. Most people who own homes think they were the primary customer of the mortgage, but that’s not true.

(Apologies in advance for this being a very specifically U.S. flavored issue of this publication. While practice in some nations—Japan comes to mind—is trending in the direction of U.S. practice, the world’s largest and most sophisticated mortgage market is also very quirky, as a result of a hundred years of policy decisions with societal-level impact. Trying to address multiple nations’ takes on this instrument would make this issue the length of a small encyclopedia. Also, for simplicity, we’ll largely be looking at residential mortgages rather than commercial.)

Mortgages are a manufactured product

Let’s get the most important bit out of the way first: civilians think that a mortgage is a loan between a bank and a customer, and think of it primarily as services work (to the extent they think of it at all). This is a materially incorrect worldview, which drives much confusion about how the industry (and mortgages) function, both among people who can’t be expected to know better (customers) and people who probably could (regulators and journalists, among many others).

A mortgage is a product, which is built by specialist workers using an immense and costly capital edifice, to be sold into a supply chain for consumers of that product. It incidentally happens to involve a house and a loan, but those two facts do not drive most behaviors of the mortgage industry. The structure of the manufacturing process, and the consuming supply chain, do.

If it helps you to visualize this, think of a widget going into some hyperspecialized and boring bit of capitalism. Electronic flow meters, for example. [0] Somewhere, in fact in many somewheres, there exists a factory of people who do nothing but assemble electronic flow meters. These do exactly what they say on the tin; they measure flows of liquids or gasses using electric means. There are a lot of them in parts of the economy which push things through physical pipes, whether that is New York’s sanitation department or a steel smelter. It would be a very bad thing for the electronic flow meter factory to sell flow meters that didn’t meter flow accurately. Their consumers would hate that. Cakes would taste bad. Buildings would explode.

If you replaced your current mental model for mortgages with “it’s like a paper electronic flow meter for money, possibly with less paper these days”, it would improve your ability to understand the mortgage industry. The analogy is less about providing visibility into the contents of pipes (though mortgages must do that) and more “highly specialized manufactured widget that the entire world sits downstream of.”

Who manufactures mortgages?

Mortgages are written by originators. The first and most thorough misconception the public has about mortgages is that they’re written by lenders. Originators can be lenders, and historically generally were, but these days they generally are not. The people who make electronic flow meters do not also run the cake-baking factory as a fun hobby. Those are entirely different skillsets. They sell the thing they make, through a fairly complex value chain, to the cake-baking factory.

Of the top 15 mortgage originators in the U.S., only four are banks (Bank of America, Chase, U.S. Bank, and Wells Fargo), and most of those banks’ mortgage volume originate-for-sale rather than originate-to-lend. The remainder are all pure-play mortgage firms, some of which you’ve probably heard of due to direct-to-consumer marketing (RocketMortgage, Guaranteed Rate, etc) and some of which are more obscure (despite writing tens of billions of dollars of mortgages). This is due to a difference in operational models for them; we’ll get to that in a later issue.

So who actually has their hands on the tools in the mortgage factory? Every mortgage is a collaboration between:

The front office: A sales professional, called a loan officer by convention (and usually referred to in the industry as “a producer”). Their job is to interface with the home buyer, educate them on the most complicated and high-stakes financial decision they’ll have to make in their lives, and project manage the financial side of a real estate close. This will include a backbreaking amount of passing documents to…

The back office: Approximately 1.5 professionals per loan officer, who are responsible for making sure electronic flow meters are properly calibrated. Oops, wrong side of the analogy. No, they are responsible for making sure that the physical instantiation of the mortgage, 700 pages of documents or so, will pass the strict acceptance tests of the value chain that sells mortgages to end-users of mortgages.

The industry operates, as many people who have interacted with it can attest, in a disturbingly artisanal manner for a trillion dollar manufacturing sector which props up a huge portion of the economy. As the person buying a house, you care tremendously about the professional skill levels of your loan officer in a way which you never really care about the professional skill levels of the person who assembled your phone.

Who buys mortgages?

In a typical manufacturing supply chain, the box with the thing in it passes through different hands, or the thing gets incorporated into increasingly complex assemblies. In the mortgage supply chain, the thing gets split apart and (sometimes) repackaged into other things.

The manufactured product which is a mortgage is a collection of risks. The finance industry and government in the United States, to be more efficient and accomplish a long list of social goals, has successfully disaggregated many of those risks. Different risks are bought by different entities.

The risk of non-payment

As a policy decision, the United States has effectively socialized most of the market for the risk of non-payment of mortgages, in the interests of making home ownership more predictably available. (Whether this makes it cheaper or more expensive on net is a complicated question to answer.)

The mechanism for this are the GSEs (government-sponsored entities), like Fannie Mae, Ginnie Mae, Freddy Mac, and the Federal Home Loans Bank. These are all privately owned entities who have CEOs, shareholders, etc etc, but they’re also policy arms of the U.S. federal government and everyone knows it. (If there was any ambiguity about that, and there was very little, the financial crisis dispelled it.)

The business model of the GSEs rounds to this: they publish the specifications for the mortgage industry. This lets you know that the electronic flow meter will work as advertised and not blow up the factory you install it in. A mortgage which fits their specifications is called “conforming.” Buyers of a conforming mortgage need inquire no further about the 700 pages of documents. They treat mortgages as black boxes with some observable metadata to them.

The GSEs monetize these specifications by writing insurance against all conforming mortgages. The insurance is against, specifically, non-payment risk. Originators of mortgages who desire to sell them into value chain overwhelmingly choose to get conforming mortgages guaranteed. The cost is below 60 basis points and ultimately borne by the home purchaser, in the form of points or interest.

The GSEs, operating as galactically sized insurance companies, profit or lose in a similar manner to insurance companies: they can use capital markets to invest the float (though, due to risks and their quixotic relationship with the Treasury, they cannot be as aggressive as e.g. Berkshire Hathaway) and hope to earn an underwriting profit. That is, they hope the specifications they write and rigorously enforce correctly predict and price default risk. This was resoundingly not true in the run-up to the global financial crisis, which resulted in large government bailouts and a sort of quasi-nationalization of them.

(There has been some limited experimentation with privatizing the risk of non-payment again, via mechanisms like Freddie Mac’s Credit Risk Transfer product, but the GSEs will happily tell you that most is currently borne by the taxpayer.)

The risk of failing to service a mortgage correctly

A mortgage has a quirky little subcomponent called a Mortgage Servicing Right (MSR). Every month, it needs to collect money from the borrower and send that money… somewhere. This implies, minimally, a mailbox where you can send checks, someone to open the mail, and a phone number with a CS representative who can answer questions like “What is my current balance?” and “Did you get the last check I sent you?”

The holder of an MSR has an obligation to the owner(s) of the mortgage to not screw this up, enforced both by contract and by quite a bit of regulatory supervision. In return for taking on the boring business of opening letters and answering phone calls, they’re paid a small cut of the incoming payments. This generally works out to about 25 basis points of outstanding principal.

Their obligations are actually more complicated than this quick sketch, particularly in unhappy cases like e.g. when someone defaults on their mortgage. It’s an operationally intensive business to be in.

Importantly, MSRs trade some amount of work you could build a giant human-powered machine to do for a stream of ongoing payments. The finance industry loves that sort of stuff, and has built a large system to buy and sell MSRs. This results in the servicing of mortgages migrating to large players who have huge economies of scale to open letters and answer phone calls. It also confuses many people who walked into e.g. a Citibank to get their mortgage and think that this means Citibank will own the mortgage (probably not) or take checks from them for it (probably not).

Every other risk you could imagine, of which there are many

Private capital buys all the other risks. The How of that will have to wait for a future issue.

We can get into part of the What, though, right now.

A mortgage, like any manufactured product, has a value. You can go to your friendly neighborhood seller of mortgages and buy mortgages in any size or shape. If your factory needs a flow meter, someone has a flow meter for you and can tell you what it costs; they probably didn’t build the flow meter with their own two hands.

The value of the mortgage is not the outstanding principal, any more than the value of a flow meter is the maximum rate of water flowing through it. That is an important technical feature of the artifact at issue, but is not the price tag.

The value of flow meters goes up when there are more companies wanting to buy them in a time period than factories can manufacture them in the same time period, and down when the reverse is true. That happens to mortgages, too; supply and demand is a thing.

One driver of supply and demand is the interest rate environment, which is not entirely external to the mortgage market but which you can assume is for simplicity. All existing loans, including mortgages, become less valuable when interest rates go up and more valuable when interest rates go down. (The easy way to remember this: pretend you bought a widget for $100 which spit out $5 a year. If the new model of widgets spits out $6 a year and also costs $100 new, will anyone buy your perfectly functioning used widget for $100? No, that’s silly; they’d buy the new one. You have to offer them a discount until the yield matches that of the new model.)

This is one of the reasons why society has arranged it so that banks don’t own most mortgages. For a very, very long time, banks were primarily engaged in the business of maturity transformation; they would borrow money short term from depositors at low interest rates and lend it long-term, mostly to mortgage borrowers, at a higher interest rate.

We have learned, through long and painful experience, that this is an extremely repeatable recipe for banking crises. Interest rates go up, which increases banks funding costs and decreases the value of all the mortgages they own. (It also decreases the number of re-finances they sell, because they are now mechanically more expensive, but that’s a relatively minor factor.) If the bank is not sufficiently capitalized, to maintain their reserves (and have adequate liquidity to meet responsibilities to customers and regulators) they’ll have to sell some of those now less-valuable mortgages.

All banks experience the same pressure effectively simultaneously; supply and demand hits the value for mortgages and their values start to plummet; the book value of mortgages at other banks now means they’re under-reserved and so have to sell mortgages to raise liquidity; this creates a vicious circle in the banking sector.

A widespread misconception about mortgage securitization is that it was created to make Wall Street rich. This is a popular narrative, especially due to Michael Lewis’ best book (and one of the best finance movies ever made). This narrative is… incomplete.

Mortgage securitization, and secondary sales of loans, and other mechanisms cause mortgages to migrate from the banking sector to pools of capital which are more structurally insulated against the interest rate cycle.

A pension fund turns out to be a great counterparty to a mortgage, for example. They have known needs for cash in the short term and, if interest rates rise, that is generally good news to them. (It decreases the net present value of their funding shortfall for future commitments.) Their pile of mortgages would be worth less if they sold them but they do not structurally need to be sellers.

The pension fund cannot manufacture mortgages. That requires complex technology and a team of professionals that they do not have. They do not ever desire to write mortgages. They just want the economic exposure those mortgages represent, and they want it more than banks do.

It turns out, counterintuitively, that there are many, many buyers in the world who want to own mortgages more than banks do. They end up owning almost all of the mortgages, for fundamentally the same reason that the electronic flow meter factory ends up owning very few of the world’s current stock of flow meters. Someone has a better use for them and they exist to supply that better use, not to finance it.

Scratching the tip of the iceberg

We will return to the topic of mortgage finance, and the plumbing underlying them, in future installments of Bits about Money. But if you wanted to read about it right now, here are some excellent entry points:

Digitally Transforming the Mortgage Banking Industry. If you want to know how the sausage is made, this is the best account of it. I would read it critically; the author is from the sales side of the industry and is, ahem, in a position where they have to understand software to a greater degree than they actually do. Still, it’s a great look at mortgage origination where the forged bank statement hits the underwriter.

The 30-Year Mortgage is an Intrinsically Toxic Product by Byrne Hobart (who also writes a very good newsletter). This is lay-accessible but deep on both financial wonkery and housing policy.

The Dead Pledge. A scholarly history work on the pre-war years of mortgage finance, in whose shadow much of the U.S. economy (and social organization) now sits.

[0] My quixotic level of interest in electronic flow meters is on account of my best salaryman friend working at the company which makes the best electronic flow meters. I have had many long chats with him about the science of flow meters, the challenges of being a Japanese salaryman walking through customs in the Middle East with a suitcase full of sample flow meters, and the surprising difficulty of translating flow meter marketing copy into English. (For social reasons, I'll elide naming him or the company, but statistically speaking you are overwhelmingly likely to be... downstream of their work.)

← Finality does not exist in payments
BNPLs: Businesses Needing Provided Legibility →

Want more essays in your inbox?

I write about the intersection of tech and finance, approximately biweekly. It's free.

Get a biweekly email

Great! Check your inbox (or spam folder) for an email containing a magic link.

Sorry, something went wrong. Please try again.

Intel undercut a standards body to give us the PCI connector

spectrum.ieee.org - Comments

A version of this post originally appeared on Tedium, Ernie Smith’s newsletter, which hunts for the end of the long tail.

Personal computing has changed a lot in the past four decades, and one of the biggest changes, perhaps the most unheralded, comes down to compatibility. These days, you generally can’t fry a computer by plugging in a joystick that the computer doesn’t support. Simply put, standardization slowly fixed this. One of the best examples of a bedrock standard is the peripheral component interconnect, or PCI, which came about in the early 1990s and appeared in some of the decade’s earliest consumer machines three decades ago this year. To this day, PCI slots are used to connect network cards, sound cards, disc controllers, and other peripherals to computer motherboards via a bus that carries data and control signals. PCI’s lessons gradually shaped other standards, like USB, and ultimately made computers less frustrating. So how did we get it? Through a moment of canny deception.

Commercial - Intel Inside Pentium Processor (1994)www.youtube.com

Embracing standards: the computing industry’s gift to itself

In the 1980s, when you used the likes of an Apple II or a Commodore 64 or an MS-DOS machine, you were essentially locked into an ecosystem. Floppy disks often weren’t compatible. The peripherals didn’t work across platforms. If you wanted to sell hardware in the 1980s, you were stuck building multiple versions of the same device.

For example, the KoalaPad was a common drawing tool sold in the early 1980s for numerous platforms, including the Atari 800, the Apple II, the TRS-80, the Commodore 64, and the IBM PC. It was essentially the same device on every platform, and yet, KoalaPad’s manufacturer, Koala Technologies, had to make five different versions of this device, with five different manufacturing processes, five different connectors, five different software packages, and a lot of overhead. It was wasteful, made being a hardware manufacturer more costly, and added to consumer confusion.

Drawing on a 1983 KoalaPad (Apple IIe)www.youtube.com

This slowly began to change in around 1982, when the market of IBM PC clones started taking off. It was a happy accident—IBM’s decision to use a bunch of off-the-shelf components for its PC accidentally turned them into a de facto standard. Gradually, it became harder for computing platforms to become islands unto themselves. Even when IBM itself tried and failed to sell the computing world on a bunch of proprietary standards in its PS/2 line, it didn’t work. The cat was already out of the bag. It was too late.

So how did we end up with the standards that we have today, and the PCI expansion card standard specifically? PCI wasn’t the only game in town—you could argue, for example, that if things played out differently, we’d all be using NuBus or Micro Channel architecture. But it was a standard seemingly for the long haul, far beyond other competing standards of its era.

Who’s responsible for spearheading this standard? Intel. While PCI was a cross-platform technology, it proved to be an important strategy for the chipmaker to consolidate its power over the PC market at a time when IBM had taken its foot off the gas, choosing to focus on its own PowerPC architecture and narrower plays like the ThinkPad instead, and was no longer shaping the architecture of the PC.

The vision of PCI was simple: an interconnect standard that was not intended to be limited to one line of processors or one bus. But don’t mistake standardization for cooperation. PCI was a chess piece—a part of a different game than the one PC manufacturers were playing.

The PCI standard and its derivatives have endured for over three decades. Modern computers with a GPU often use a PCIe interconnect. Alamy

In the early 1990s, Intel needed a win

In the years before Intel’s Pentium chipset came out in 1993, there seemed to be some skepticism about whether Intel could maintain its status at the forefront of the desktop-computing field.

In lower-end consumer machines, players like Advanced Micro Devices (AMD) andCyrix were starting to shake their weight around. At the high end of the professional market, workstation-level computing from the likes of Sun Microsystems, Silicon Graphics, and Digital Equipment Corporation suggested there wasn’t room for Intel in the long run. And laterally, the company suddenly found itself competing with a triple threat of IBM, Motorola, and Apple, whose PowerPC chip was about to hit the market.

A Bloomberg piece from the period painted Intel as being boxed in between these various extremes:

If its rivals keep gaining, Intel could eventually lose ground all around.

This is no idle threat. Cyrix Corp. and Chips & Technologies Inc. have re-created—and improved—Intel’s 386 without, they say, violating copyrights or patents. AMD has at least temporarily won the right in court to make 386 clones under a licensing deal that Intel canceled in 1985. In the past 12 months, AMD has won 40% of a market that since 1985 has given Intel $2 billion in profits and a $2.3 billion cash hoard. The 486 may suffer next. Intel has been cutting its prices faster than for any new chip in its history. And in mid-May, it chopped 50% more from one model after Cyrix announced a chip with some similar features. Although the average price of a 486 is still four times that of a 386, analysts say Intel’s profits may grow less than 5% this year, to about $850 million.

Intel’s chips face another challenge, too. Ebbing demand for personal computers has slowed innovation in advanced PCs. This has left a gap at the top—and most profitable—end of the desktop market that Sun, Hewlett-Packard Co., and other makers of powerful workstations are working to fill. Thanks to microprocessors based on a technology known as RISC, or reduced instruction-set computing, workstations have dazzling graphics and more oomph—handy for doing complex tasks and moving data faster over networks. And some are as cheap as high-end PCs. So the workstation makers are now making inroads among such PC buyers as stock traders, banks, and airlines.

This was a deep underestimation of Intel’s market position, it turned out. The company was actually well-positioned to shape the direction of the industry through standardization. They had a direct say on what appeared on the motherboards of millions of computers, and that gave them impressive power to wield. If Intel didn’t want to support a given standard, that standard would likely be dead in the water.

How Intel crushed a standards body on the way to giving us an essential technology

The Video Electronics Standards Association, or VESA, is perhaps best known today for its mounting system for computer monitors and itsDisplayPort technology. But in the early 1990s, it was working on a video-focused successor to the Industry Standard Architecture (ISA) internal bus, widely used in IBM PC clones.

A bus, the physical wiring that lets a CPU talk to internal and external peripheral devices, is something of a bedrock of computing—and in the wrong setting, a bottleneck. The ISA expansion card slot, which had become a de facto standard in the 1980s, had given the IBM PC clone market something to build against during its first decade. But by the early 1990s, for high-bandwidth applications, particularly video, it was holding back innovation. It just wasn’t fast enough to keep up, even after it had been upgraded from being able to handle 8 bits of data at once to 16.

That’s where the VESA Local Bus (VL-Bus) came into play. Built to work only with video cards, the standard offered a faster connection, and could handle 32 bits of data. It was targeted at the Super VGA standard, which offered higher resolution (up to 1280 x 1024 pixels) and richer colors at a time when Windows was finally starting to take hold in the market. To overcome the limitations of the ISA bus, graphics card and motherboard manufacturers started collaborating on proprietary interfaces, creating an array of incompatible graphics buses. The lack of a consistent experience around Super VGA led to VESA’s formation. The new VESA slot, which extended the existing 16-bit ISA bus with an additional 32-bit video-specific connector, was an attempt to fix that.

It wasn’t a massive leap—more like a stopgap improvement on the way to better graphics.

And it looked like Intel was going to go for the VL-BUS. But there was one problem—Intel actually wasn’t feeling it, and Intel didn’t exactly make that point clear to the companies supporting the VESA standards body until it was too late for them to react.

Intel revealed its hand in an interesting way, according to TheSan Francisco Examinertech reporter Gina Smith:

Until now, virtually everyone expected VESA’s so-called VL-Bus technology to be the standard for building local bus products. But just two weeks before VESA was planning to announce what it came up with, Intel floored the VESA local bus committee by saying it won’t support the technology after all. In a letter sent to VESA local bus committee officials, Intel stated that supporting VESA’s local bus technology “was no longer in Intel’s best interest.” And sources say it went on to suggest that VESA and Intel should work together to minimize the negative press impact that might arise from the decision.

Good luck, Intel. Because now that Intel plans to announce a competing group that includes hardware heavyweights like IBM, Compaq, NCR and DEC, customers and investors (and yes, the press) are going to wonder what in the world is going on.

Not surprisingly, the people who work for VESA are hurt, confused and angry. “It’s a political nightmare. We’re extremely surprised they’re doing this,” said Ron McCabe, chairman for the committee and a product manager at VESA member Tseng Labs. “We’ll still make money and Intel will still make money, but instead of one standard, there will now be two. And it’s the customer who’s going to get hurt in the end.”

But Intel had seen an opportunity to put its imprint on the computing industry. That opportunity came in the form of PCI, a technology that the firm’s Intel Architecture Labs started developing around 1990, two years before the fateful rejection of VESA. Essentially, Intel had been playing both sides on the standards front.

Why PCI

Why make such a hard shift, screwing over a trusted industry standards body out of nowhere? Beyond wanting to put its mark on the standard, Intel also saw an opportunity to build something more future-proof; something that could benefit not just graphic cards but every expansion card in the machine.

As John R. Quinn wrote in PC Magazine in 1992:

Intel’s PCI bus specification requires more work on the part of peripheral chip-makers, but offers several theoretical advantages over the VL-Bus. In the first place, the specification allows up to ten peripherals to work on the PCI bus (including the PCI controller and an optional expansion-bus controller for ISA, EISA, or MCA). It, too, is limited to 33 MHz, but it allows the PCI controller to use a 32-bit or a 64-bit data connection to the CPU.

In addition, the PCI specification allows the CPU to run concurrently with bus-mastering peripherals—a necessary capability for future multimedia tasks. And the Intel approach allows a full burst mode for reads and writes (Intel’s 486 only allows bursts on reads).

Essentially, the PCI architecture is a CPU-to-local bus bridge with FIFO (first in, first out) buffers. Intel calls it an “intermediate” bus because it is designed to uncouple the CPU from the expansion bus while maintaining a 33-MHz 32-bit path to peripheral devices. By taking this approach, the PCI controller makes it possible to queue writes and reads between the CPU and PCI peripherals. In theory, this would enable manufacturers to use a single motherboard design for several generations of CPUs. It also means more sophisticated controller logic is necessary for the PCI interface and peripheral chips.

To put that all another way, VESA came up with a slightly faster bus standard for the next generation of graphics cards, one just fast enough to meet the needs of Intel’s recent i486 microprocessor users. Intel came up with an interface designed to reshape the next decade of computing, one that it would let its competitors use. This bus would allow people to upgrade their processor across generations without needing to upgrade their motherboard. Intel brought a gun to a knife fight, and it made the whole debate about VL-Bus seem insignificant in short order.

The result was that, no matter how miffed the VESA folks were, Intel had consolidated power for itself by creating an open standard that would eventually win the next generation of computers. Sure, Intel let other companies use the PCI standard, even companies like Apple that weren’t directly doing business with Intel on the CPU side. But Intel, by pushing forth PCI, suddenly made itself relevant to the entire next generation of the computing industry in a way that ensured it would have a second foothold in hardware. The “Intel Inside” marketing label was not limited to the processors, as it turned out.

The influence of Intel’s introduction of PCI is still felt: Thirty-two years later, and three decades after PCI became a major consumer standard, we’re still using PCI derivatives in modern computing devices.

PCI and other standards

Looking at PCI, and its successor PCI express, less as ways that we connect the peripherals we use with our computers, and more as a way for Intel to maintain its dominance over the PC industry, highlights something fascinating about standardization.

It turns out that perhaps Intel’s greatest investment in computing in the 1990s was not the Pentium chipset, but its investment in Intel Architecture Labs, which quietly made the entire computing industry better by working on the things that frustrated consumers and manufacturers alike.

Essentially, as IBM had begun to take its eye off the massive clone market it unwittingly built during this period, Intel used standardization to fill the power void. It worked pretty well, and made the company integral to computer hardware beyond the CPU. In fact, devices you use daily—that Intel played zero part in creating—have benefited greatly from the company’s standards work. If you’ve ever used a device with a USB or Bluetooth connection, you can thank Intel for that.

Craig Kinnie, the director of Intel Architecture Labs in the 1990s, said it best in 1995, upon coming to an agreement with Microsoft on a 3D graphics architecture for the PC platform. “What’s important to us is we move in the same direction,” he said. “We are working on convergent paths now.”

That was about collaborating with Microsoft. But really, it has been Intel’s modus operandi for decades—what’s good for the technology field is good for Intel. Innovations developed or invented by Intel—like Thunderbolt, Ultrabooks, and Next Unit Computers (NUCs)—have done much to shape the way we buy and use computers.

For all the talk of Moore’s Law as a driving factor behind Intel’s success, the true story might be its sheer cat-herding capabilities. The company that builds the standards builds the industry. Even as Intel faces increasing competition from alliterative processing players like ARM, Apple, and AMD, as long as it doesn’t lose sight of the roles standards played in its success, it might just hold on a few years longer.

Ironically, Intel’s standards-driving winning streak, now more than three decades old, might have all started the day it decided to walk out on a standards body.

From Your Site Articles

Related Articles Around the Web

Apache NuttX RTOS on Sophgo SG2000 RISC-V SoC (Milk-V Duo S SBC)

lupyuen.codeberg.page - Comments

Pick another theme!

📝 19 May 2024

Milk-V Duo S SBC with SG2000 RISC-V SoC

Soon we’ll see many new 64-bit RISC-V SBCs based on the Sophgo SG2000 RISC-V SoC.

Will they work with Apache NuttX RTOS? (Real-Time Operating System) Let’s find out…

  • We boot Linux on Milk-V Duo S (with SG2000)

  • Peek inside SG2000 Linux and observe how it boots

  • Then we take NuttX for RISC-V (Ox64 BL808)

  • Tweak NuttX Kernel to boot on SG2000

  • Fix the (undocumented) Interrupt Controller

  • And Milk-V Duo S boots to a fully-functional NuttX Shell

Something strangely satisfying about NuttX on RISC-V… We finished the port in Only 10 Days 🎉

(Is this a sponsored review? I was given a Milk-V Duo S, and I bought another. So it cancels out I guess?)

Sophgo SG2000 RISC-V SoC

Sophgo SG2000 SoC has a fascinating mix of 64-bit RISC-V Cores (Arm too)…

  • Main Processor: 64-bit RISC-V Core

    T-Head C906 (1.0 GHz)

    (For NuttX and Linux)

  • Co-Processor: 64-bit RISC-V Core

    T-Head C906 (700 MHz)

    (No Cache)

  • Alt-Main Processor: 64-bit Arm Core

    Cortex-A53 (1.0 GHz)

Plus a Low-Power 8051 MCU (for Wakeup Duties) and a Tensor Processing Unit (for Image Recognition, not LLM)

Sophgo SG2000 RISC-V SoC

(See the SG2000 Reference Manual)

(See the Cvitek SDK Docs)

Whoa RISC-V AND Arm CPUs in a single SoC?

Actually there’s a Physical Switch that selects the Main CPU: RISC-V OR Arm.

Don’t let yer pet hamster flip it… It will get super frustrating!

(Sophgo / Sophon.ai comes from 3 Body)

Milk-V Duo S SBC with SG2000 RISC-V SoC

What happens if we boot Milk-V Duo S? Fresh from the box?

Connect our USB UART Dongle according to the instructions (pic above)…

Milk-V Duo SUSB UART
GND (Pin 6)GND
TX (Pin 8)RX
RX (Pin 10)TX

USB UART Dongle must be CP2102, it doesn’t like CH340 😬

Switch to “RV” (RISC-V) instead of “Arm”

Flip the Switch so it’s set to “RV” (RISC-V) instead of “Arm”. (Pic above)

Power up the board via the USB-C Port. Connect to the USB UART at 115.2 kbps.

Milk-V Duo S won’t boot because it doesn’t ship with U-Boot Bootloader in Flash Memory…

C.SCS/0/0.WD.URPL.USBI.USBEF.BS/EMMC.EMI/25000000/12000000. 
E:eMMC initializing failed
E:Boot failed
E:RESET:plat/mars/platform.c:114

We’ll need U-Boot on MicroSD, in the next section.

(platform.c might be here)

If we see B.SCS instead of “C.SCS”…

B.SCS/0/0.WD.URPL.USBI.USBEF.BS/EMMC.EMI/25000000/12000000.

Nope we’re in Arm Mode… Flip the switch back to RISC-V!

If we use CH340 (instead of CP2102): UART Output will be gloriously garbled.

Debian Image for Sophgo SG2000

Milk-V Duo S won’t boot without MicroSD. How now?

We boot Linux on MicroSD, thanks to the awesome work by Justin Hammond (Fishwaldo)…

We download the Latest Release for Milk-V Duo S (SG2000)…

Uncompress the Debian Image…

## For Linux:
$ sudo apt install lz4

## For macOS:
$ brew install lz4

## Uncompress the download to get `duos_sd.img`
$ lz4 duos_sd.img.lz4

And write duos_sd.img to a MicroSD Card. Use Balena Etcher, GNOME Disks or dd.

We’ll see these MicroSD Files

## MicroSD Root Folder
$ ls -l /Volumes/boot
-rwx 3494900 System.map-5.10.4-20240329-1+
-rwx  125534 config-5.10.4-20240329-1+
drwx    2048 extlinux
drwx    2048 fdt
-rwx  388608 fip.bin
-rwx 4937389 vmlinuz-5.10.4-20240329-1+

## U-Boot Bootloader Config
$ ls -l /Volumes/boot/extlinux
-rwx 749 extlinux.conf

## Linux Device Tree for SG2000
$ ls -l /Volumes/boot/fdt/linux-image-duos-5.10.4-20240329-1+
-rwx 21575 cv181x_milkv_duos_sd.dtb

We peek at the U-Boot Bootloader Config (which will boot NuttX with a tiny tweak)

$ cat /Volumes/boot/extlinux/extlinux.conf
...
menu label Debian GNU/Linux trixie/sid 5.10.4-20240329-1+
linux  /vmlinuz-5.10.4-20240329-1+
fdtdir /fdt/linux-image-duos-5.10.4-20240329-1+/
append root=/dev/root console=ttyS0,115200 earlycon=sbi root=/dev/mmcblk0p2 rootwait rw

Watch what happens when we boot the MicroSD…

OpenSBI and U-Boot Bootloader

Linux on MicroSD: Will it boot on Milk-V Duo S?

Yep Linux boots OK. First we see OpenSBI (Supervisor Binary Interface)

OpenSBI v0.9
Platform Name       : Milk-V DuoS
Platform Features   : mfdeleg
Platform HART Count : 1
Platform Console Device : uart8250
Firmware Base       : 0x8000_0000
Firmware Size       : 132 KB
Runtime SBI Version : 0.3

Domain0 Region00 : 0x7400_0000-0x7400_ffff (I)
Domain0 Region01 : 0x8000_0000-0x8003_ffff ()
Domain0 Region02 : 0x0-0xffff_ffff_ffff_ffff (R,W,X)
Boot HART ISA      : rv64imafdcvsux
Boot HART Features : scounteren,mcounteren,time
Boot HART MIDELEG  : 0x0222
Boot HART MEDELEG  : 0xb109

## OpenSBI boots at 0x8000_0000.
## 0x7400_0000 looks interesting! We'll come back to this

(See the Complete Log)

Followed by the U-Boot Bootloader

## U-Boot Boots
U-Boot 2021.10-ga57aa1f2-dirty (Apr 24 2024 - 11:24:46 +0000) cvitek_cv181x
Hit any key to stop autoboot:  0 
Scanning mmc 0:1...
Found /extlinux/extlinux.conf

## U-Boot Menu
1:.Debian GNU/Linux trixie/sid 5.10.4-20240329-1+
2:.Debian GNU/Linux trixie/sid 5.10.4-20240329-1+ (rescue target)
Enter choice: 1

## U-Boot boots Debian Linux
Retrieving file: /vmlinuz-5.10.4-20240329-1+
Retrieving file: /fdt/linux-image-duos-5.10.4-20240329-1+/cv181x_milkv_duos_sd.dtb
Booting using the fdt blob at 0x81200000

Finally we see Debian Linux

Starting kernel ...
Linux version 5.10.4-20240329-1+ (root@3abcc283c6ba) (riscv64-unknown-linux-musl-gcc (Xuantie-900 linux-5.10.4 musl gcc Toolchain V2.6.1 B-20220906) 10.2.0, GNU ld (GNU Binutils) 2.35)
...
Debian GNU/Linux trixie/sid duos ttyS0
duos login: 

Linux works great, we hop over to NuttX…

(Cvitek is the old name of Sophgo / Sophon)

U-Boot Bootloader

How will we boot NuttX?

We seek guidance from the U-Boot Bootloader.

As we power on Milk-V Duo S, hit Enter a few times to see the U-Boot Command Prompt

U-Boot 2021.10-ga57aa1f2-dirty (May 07 2024 - 08:13:12 +0000) cvitek_cv181x
Loading Environment from FAT... mmc1 : finished tuning, code:53
Hit any key to stop autoboot:  0
cv181x_c906# 

Enter printenv to dump the U-Boot Settings…

## U-Boot Settings
$ printenv
kernel_addr_r=0x80200000
kernel_comp_addr_r=0x81800000
kernel_comp_size=0x1000000
ramdisk_addr_r=0x84000000
uImage_addr=0x81800000
update_addr=0x9fe00000

(See the U-Boot Settings)

kernel_addr_r says that U-Boot will load Linux Kernel into RAM at Address 0x8020_0000. (We’ll set this in NuttX)

And the Ethernet Driver is fully operational in U-Boot. Which means we can boot NuttX over the Network

$ net list
eth0: ethernet@4070000
00:00:00:00:00:00
active

Here’s how…

(See the U-Boot Commands)

Boot NuttX over TFTP

What’s the quickest way to port NuttX to SG2000?

Like Linux, we could copy NuttX to MicroSD, insert into Milk-V Duo S and power up. Again and again and again

But there’s a quicker way: Boot NuttX over the Network, thanks to U-Boot Bootloader and TFTP (Trivial File Transfer Protocol)

Follow the instructions here to install our TFTP Server. Copy these files to our TFTP Server…

At the U-Boot Command Prompt: We configure our TFTP Server

## Set the U-Boot TFTP Server
## TODO: Change to your TFTP Server
setenv tftp_server 192.168.31.10

## If Initial RAM Disk is needed (like for Linux, not for NuttX)...
## Set the RAM Disk Size (assume the max)
## setenv ramdisk_size 0x1000000

## Save the U-Boot Config for future reboots
saveenv

Then we load the NuttX Image into RAM over TFTP…

## Fetch the IP Address over DHCP
## Load the NuttX Image from TFTP Server
## kernel_addr_r=0x80200000
dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000

## Load the Device Tree from TFTP Server
## fdt_addr_r=0x81200000
## TODO: Fix the Device Tree, it's not needed by NuttX
tftpboot ${fdt_addr_r} ${tftp_server}:cv181x_milkv_duos_sd.dtb

## Set the RAM Address of Device Tree
## fdt_addr_r=0x81200000
## TODO: Fix the Device Tree, it's not needed by NuttX
fdt addr ${fdt_addr_r}

## If Initial RAM Disk is needed...
## Load the Intial RAM Disk from TFTP Server
## ramdisk_addr_r=0x81600000
## tftpboot ${ramdisk_addr_r} ${tftp_server}:initrd

And we boot NuttX from RAM

## Boot the NuttX Image with the Device Tree
## kernel_addr_r=0x80200000
## fdt_addr_r=0x81200000
## TODO: Fix the Device Tree, it's not needed by NuttX
booti ${kernel_addr_r} - ${fdt_addr_r}

## For Linux: We need the RAM Disk Address
## ramdisk_addr_r=0x81600000
## ramdisk_size=0x1000000
## booti ${kernel_addr_r} ${ramdisk_addr_r}:${ramdisk_size} ${fdt_addr_r}

What happens when we boot NuttX?

Absolutely nothing…

## Boot NuttX over TFTP, mashed up in a single line...
$ dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000 ; tftpboot ${fdt_addr_r} ${tftp_server}:cv181x_milkv_duos_sd.dtb ; fdt addr ${fdt_addr_r} ; booti ${kernel_addr_r} - ${fdt_addr_r}

Booting using the fdt blob at 0x81200000
Loading Ramdisk to 9e27f000, end 9f27f000 ... OK
Loading Device Tree to 9e26f000, end 9e27e43a ... OK
Starting kernel ...

But that’s OK, we haven’t modified NuttX Kernel for SG2000. We’ll print something in a while.

We type these commands EVERY TIME we boot?

We can automate: Just do this once, and NuttX will Auto-Boot whenever we power up…

## Add the Boot Command for TFTP
setenv bootcmd_tftp 'dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000 ; tftpboot ${fdt_addr_r} ${tftp_server}:cv181x_milkv_duos_sd.dtb ; fdt addr ${fdt_addr_r} ; booti ${kernel_addr_r} - ${fdt_addr_r}'

## Save it for future reboots
saveenv

## Test the Boot Command for TFTP, then reboot
run bootcmd_tftp

## Remember the Original Boot Targets: `mmc0 dhcp pxe`
setenv orig_boot_targets "$boot_targets"

## Prepend TFTP to the Boot Targets: `tftp mmc0 dhcp pxe`
setenv boot_targets "tftp $boot_targets"

## Save it for future reboots
saveenv

(What about Static IP?)

(How to Undo Auto-Boot)

UART Controller for SG2000

How will NuttX print to the Serial Console?

First we track down the UART Controller for SG2000.

From SG2000 Reference Manual (Page 638): The UART Controller is at these Base Addresses (we’ll talk to UART0)

UART ModuleBase Address
UART00x0414_0000
UART10x0415_0000
UART20x0416_0000
UART30x0417_0000
UART40x041C_0000
RTCSYS_UART0x0502_2000

What UART Controller is inside SG2000?

According to OpenSBI Log: The UART Controller is uart8250.

Which is supported by NuttX. We mod the NuttX Boot Code to print something…

Print to UART in RISC-V Assembly

Printing in RISC-V Assembly? Why not C?

That’s because the very first thing that boots is the NuttX Boot Code in RISC-V Assembly (instead of C)…

SG2000 UART0 Controller is at 0x0414_0000 (previous section). To print something, we write to the UART Output Register at that address: bl808_head.S

/* RISC-V Boot Code for Apache NuttX RTOS */
real_start:

  /* Print `123` to UART */
  /* Load UART Base Address to Register t0 */
  li  t0, 0x04140000

  /* Load `1` to Register t1 */
  li  t1, 0x31
  /* Store byte from Register t1 to UART Base Address, Offset 0 */
  sb  t1, 0(t0)

  /* Load `2` to Register t1 */
  li  t1, 0x32
  /* Store byte from Register t1 to UART Base Address, Offset 0 */
  sb  t1, 0(t0)

  /* Load `3` to Register t1 */
  li  t1, 0x33
  /* Store byte from Register t1 to UART Base Address, Offset 0 */
  sb  t1, 0(t0)

(li loads a Value into a Register)

(sb stores a byte from a Register into an Address)

Our code will print “123” when NuttX boots. We test this…

Follow these steps to build Apache NuttX RTOS for SG2000 and Milk-V Duo S…

This produces the NuttX Image File: Image-sg2000. Which we copy to our TFTP Server

## Copy NuttX Image and Device Tree to TFTP Server
## TODO: Change `tftpserver` and `tftpboot` to our TFTP Server and Path
scp Image-sg2000 \
  tftpserver:/tftpboot/Image-sg2000
scp cv181x_milkv_duos_sd.dtb \
  tftpserver:/tftpboot/cv181x_milkv_duos_sd.dtb

(cv181x_milkv_duos_sd.dtb is here)

To Boot NuttX: Run these commands at the U-Boot Command Prompt

## Load NuttX Image and Device Tree into RAM
$ dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000
$ tftpboot ${fdt_addr_r} ${tftp_server}:cv181x_milkv_duos_sd.dtb
$ fdt addr ${fdt_addr_r}

## Boot NuttX from RAM
$ booti ${kernel_addr_r} - ${fdt_addr_r}

Starting kernel ...
123

See the “123”? That’s proof that our NuttX Boot Code is actually running on SG2000 and Milk-V Duo S. We port some more…

(See the Complete Log)

NuttX Kernel Boots OK

NuttX Kernel prints “123”. What about the rest?

More mods for NuttX Kernel

  1. We set the NuttX Memory Map for SG2000: nsh/defconfig

    ## Kernel RAM
    CONFIG_RAM_START=0x80200000
    CONFIG_RAM_SIZE=1048576
    

    (Explained here)

  2. Also the NuttX Linker Script: ld.script

    MEMORY {
      kflash (rx) : ORIGIN = 0x80200000, LENGTH = 2048K   /* w/ cache */
      ...
    SECTIONS {
      . = 0x80200000;
    

    (Explained here)

  3. We select the NuttX Driver for 16550 UART: nsh/defconfig

    CONFIG_16550_REGINCR=4
    CONFIG_16550_UART0=y
    CONFIG_16550_UART0_BASE=0x04140000
    CONFIG_16550_UART0_SERIAL_CONSOLE=y
    CONFIG_16550_UART=y
    CONFIG_16550_WAIT_LCR=y
    CONFIG_SERIAL_UART_ARCH_MMIO=y
    

    (Explained here)

  4. Enable Logging for NuttX Scheduler and Binary Loader: nsh/defconfig

    CONFIG_DEBUG_BINFMT=y
    CONFIG_DEBUG_BINFMT_ERROR=y
    CONFIG_DEBUG_BINFMT_WARN=y
    CONFIG_DEBUG_SCHED=y
    CONFIG_DEBUG_SCHED_ERROR=y
    CONFIG_DEBUG_SCHED_INFO=y
    CONFIG_DEBUG_SCHED_WARN=y
    

    (Explained here)

  5. And disable the PLIC Interrupt Controller (until we figure it out)

    (Explained here)

After applying the above fixes: NuttX Kernel boots successfully! (Pic above)

## Load NuttX Image and Device Tree into RAM
$ dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000
$ tftpboot ${fdt_addr_r} ${tftp_server}:cv181x_milkv_duos_sd.dtb
$ fdt addr ${fdt_addr_r}

## Boot NuttX from RAM
$ booti ${kernel_addr_r} - ${fdt_addr_r}

Starting kernel ...
123ABCnx_start: Entry
uart_register: Registering /dev/console
uart_register: Registering /dev/ttyS0
work_start_lowpri: Starting low-priority kernel worker thread(s)
nxtask_activate: lpwork pid=1,TCB=0x80408130
nxtask_activate: AppBringUp pid=2,TCB=0x80408740
nx_start_application: Starting init task: /system/bin/init
elf_symname: Symbol has no name
elf_symvalue: SHN_UNDEF: Failed to get symbol name: -3
elf_relocateadd: Section 2 reloc 2: Undefined symbol[0] has no name: -3
nxtask_activate: /system/bin/init pid=3,TCB=0x80409140
nxtask_exit: AppBringUp pid=2,TCB=0x80408740

One last thing and we’re done…

(See the Complete Log)

(Watch the Demo on YouTube)

NuttX Kernel boots all the way to NuttX Shell

NuttX Kernel boots OK. Where’s the NuttX Shell?

We won’t see the NuttX Shell until we fix the Interrupt Controller for SG2000. Which is NOT documented. (Sigh)

That’s because NuttX Shell requires UART Input Interrupts AND UART Output Interrupts, to support Console Input / Output.

Thus we sniff around and find out how the Interrupt Controller works.

  1. We dumped the Linux Device Tree for SG2000…

    ## Convert the SG2000 Device Tree
    dtc \
      -o cv181x_milkv_duos_sd.dts \
      -O dts \
      -I dtb \
      cv181x_milkv_duos_sd.dtb
    

    (Explained here)

  2. Snooped the PLIC Interrupt Controller in the Device Tree: cv181x_milkv_duos_sd.dts

    interrupt-controller@70000000 {
      riscv,ndev = <0x65>;
      riscv,max-priority = <0x07>;
      reg-names = "control";
      reg = <0x00 0x70000000 0x00 0x4000000>;
      interrupts-extended = <0x16 0xffffffff 0x16 0x09>;
      interrupt-controller;
      compatible = "riscv,plic0";
    

    (Explained here)

  3. And fixed the NuttX Driver for PLIC Interrupts: bl808_memorymap.h

    // Base Address of PLIC Interrupt Controller
    #define BL808_PLIC_BASE 0x70000000ul
    

    (Explained here)

After fixing the Interrupt Controller and UART Interrupts: Our Final NuttX Image boots all the way to NuttX Shell! (Pic above)

## Load NuttX Image and Device Tree into RAM
$ dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000
$ tftpboot ${fdt_addr_r} ${tftp_server}:cv181x_milkv_duos_sd.dtb
$ fdt addr ${fdt_addr_r}

## Boot NuttX from RAM
$ booti ${kernel_addr_r} - ${fdt_addr_r}

Starting kernel ...
NuttShell (NSH) NuttX-12.4.0

nsh> uname -a
NuttX 12.4.0 122c717 May  8 2024 18:13:30 risc-v ox64

nsh> ls
/:
 dev/
 proc/
 system/

nsh> ls /dev
/dev:
 console
 null
 ram0
 ttyS0
 zero

(See the Complete Log)

What about the rest of NuttX?

NuttX OSTest is the perfect way to test everything in NuttX…

nsh> ostest
user_main: mutex test
riscv_exception:
  EXCEPTION: Load access fault
  MCAUSE:    5
  EPC:       802189ce
  MTVAL:     0000000000000000
  Segmentation fault in PID 7: ostest

Sadly we’re hitting a RISC-V Exception: Load Access Fault. Needs more troubleshooting alamak.

(See the Complete Log)

NuttX Boot Flow

What happens exactly when NuttX boots on SG2000?

Exact same thing as NuttX booting on Ox64 BL808 SBC (pic above)…

Milk-V Duo S SBC with SG2000 RISC-V SoC

We’re eagerly awaiting the new 64-bit RISC-V SBCs based on the Sophgo SG2000 RISC-V SoC. Meanwhile we’re all prepped and ready…

  • We tested Linux on Milk-V Duo S (SG2000 inside)

  • And observed how SG2000 Linux boots

  • Then we took NuttX for Ox64 BL808

  • Tweaked the NuttX Kernel to boot on SG2000

  • Also fixed the (undocumented) Interrupt Controller

  • Milk-V Duo S now boots to a fully-functional NuttX Shell

  • Something strangely super satisfying about NuttX on SG2000… We finished the port in Only 10 Days 🎉

Up Next…

  1. We’ll Upstream SG2000 to NuttX Mainline

    (So others may contribute their code)

  2. Create an SG2000 Emulator for easier testing

    (Similar to TinyEMU for Ox64)

  3. We might run NuttX on the SG2000 Co-Processor

    (Plus SG2002 with its upsized TPU / NPU)

  4. Join me online at the Apache NuttX International Workshop

    (We’ll Q&A about Ox64 BL808 and SG2000)

Many Thanks to my GitHub Sponsors (and the awesome NuttX Community) for supporting my work! This article wouldn’t have been possible without your support.

Got a question, comment or suggestion? Create an Issue or submit a Pull Request here…

lupyuen.github.io/src/sg2000.md

Build NuttX for SG2000

In this article we took NuttX for Ox64 BL808 RISC-V SBC. Then made a few tweaks, and it boots on SG2000 and Milk-V Duo S…

  1. “Set the NuttX Memory Map”

  2. “Select the 16550 UART Driver”

  3. “Enable Logging for Scheduler”

  4. “Fix the NuttX Driver for PLIC”

Follow these steps to build (work-in-progress) Apache NuttX RTOS for SG2000 and Milk-V Duo S

Install the Build Prerequisites, skip the RISC-V Toolchain…

Download the RISC-V Toolchain for riscv64-unknown-elf (SiFive) or riscv-none-elf (xPack)…

Then Download and Build NuttX…

## For xPack Toolchain:
## Change all `riscv64-unknown-elf` to `riscv-none-elf`

set -e  #  Exit when any command fails
set -x  #  Echo commands

## Build NuttX
function build_nuttx {

  ## Go to NuttX Folder
  pushd ../nuttx

  ## Build NuttX
  make -j 8

  ## Return to previous folder
  popd
}

## Build Apps Filesystem
function build_apps {

  ## Go to NuttX Folder
  pushd ../nuttx

  ## Build Apps Filesystem
  make -j 8 export
  pushd ../apps
  ./tools/mkimport.sh -z -x ../nuttx/nuttx-export-*.tar.gz
  make -j 8 import
  popd

  ## Return to previous folder
  popd
}

## Download WIP NuttX for SG2000 (based on Ox64 BL808)
git clone --branch sg2000 \
  https://github.com/lupyuen2/wip-nuttx \
  nuttx
git clone --branch sg2000 \
  https://github.com/lupyuen2/wip-nuttx-apps \
  apps
cd nuttx

## Pull updates
git pull && git status && hash1=`git rev-parse HEAD`
pushd ../apps
git pull && git status && hash2=`git rev-parse HEAD`
popd
echo NuttX Source: https://github.com/apache/nuttx/tree/$hash1 >nuttx.hash
echo NuttX Apps: https://github.com/apache/nuttx-apps/tree/$hash2 >>nuttx.hash

## Show the version of GCC
riscv64-unknown-elf-gcc -v

## Configure the build
tools/configure.sh ox64:nsh

## Build the NuttX Kernel
build_nuttx

## Build the Apps Filesystem
build_apps

## Generate the Initial RAM Disk
genromfs -f initrd -d ../apps/bin -V "NuttXBootVol"

## Show the NuttX Kernel Size
riscv64-unknown-elf-size nuttx

## Export the Kernel Binary Image to `nuttx.bin`
riscv64-unknown-elf-objcopy \
  -O binary \
  nuttx \
  nuttx.bin

## Prepare a Padding with 64 KB of zeroes
head -c 65536 /dev/zero >/tmp/nuttx.pad

## Append the Padding and Initial RAM Disk to NuttX Kernel
cat nuttx.bin /tmp/nuttx.pad initrd \
  >Image

## Copy the NuttX Config
cp .config nuttx.config

## Dump the NuttX Kernel Disassembly to nuttx.S
riscv64-unknown-elf-objdump \
  --syms --source --reloc --demangle --line-numbers --wide \
  --debugging \
  nuttx \
  >nuttx.S \
  2>&1

## Dump the NuttX Shell Disassembly to init.S
riscv64-unknown-elf-objdump \
  --syms --source --reloc --demangle --line-numbers --wide \
  --debugging \
  ../apps/bin/init \
  >init.S \
  2>&1

## Dump the Hello Disassembly to hello.S
riscv64-unknown-elf-objdump \
  --syms --source --reloc --demangle --line-numbers --wide \
  --debugging \
  ../apps/bin/hello \
  >hello.S \
  2>&1

## Copy the NuttX Image and Device Tree to our TFTP Server.
## Device Tree is here: https://github.com/lupyuen2/wip-nuttx/releases/download/sg2000-1/cv181x_milkv_duos_sd.dtb
cp Image Image-sg2000
scp Image-sg2000 tftpserver:/tftpboot/Image-sg2000
scp cv181x_milkv_duos_sd.dtb tftpserver:/tftpboot/cv181x_milkv_duos_sd.dtb

(See the Build Outputs)

The steps above assume that we’ve installed our TFTP Server, according to the instructions here.

Then follow these steps to boot NuttX on Milk-V Duo S…

Virtual Memory for NuttX Apps

Why the RAM Disk? Isn’t NuttX an RTOS?

SG2000 uses a RAM Disk because it runs in NuttX Kernel Mode (instead of the typical Flat Mode). This means we can do Memory Protection and Virtual Memory for Apps. (Pic above)

But it also means we need to bundle the NuttX Apps as ELF Files, hence the RAM Disk…

Most of the NuttX Platforms run on NuttX Flat Mode, which has NuttX Apps Statically-Linked into the NuttX Kernel.

NuttX Flat Mode works well for Small Microcontrollers. But SG2000 and other SoCs will need the more sophisticated NuttX Kernel Mode

Porting NuttX to SG2000

How did we port NuttX to SG2000?

We started with NuttX for Ox64 BL808 RISC-V SBC. Then made a few tweaks, and it boots on SG2000 and Milk-V Duo S. This chapter explains the minor tweaks that we made. (Pic above)

Why did we start with NuttX for Ox64?

That’s because Ox64 BL808 runs on the same RISC-V Core as SG2000: T-Head C906.

What about the T-Head Extensions for C906?

Yep we copied (unchanged) the T-Head Extensions for C906 from Ox64 BL808 to SG2000. And they work hunky dory on SG2000…

Let’s talk about the tweaks…

§14.1 NuttX Memory Map

From U-Boot Bootloader Settings: We see that SG2000 boots at this address…

Thus we define the NuttX Memory Map for SG2000 like so…

NuttX Kernel will boot at 0x8020_0000, NuttX Apps will run at Virtual Address 0xC000_0000.

Here’s the NuttX Config: nsh/defconfig

## Kernel RAM
## TODO: Fix the size
CONFIG_RAM_START=0x80200000
CONFIG_RAM_SIZE=1048576

## Kernel Paged Pool (Allocated to NuttX Apps)
## TODO: Fix the size
CONFIG_ARCH_PGPOOL_PBASE=0x80600000
CONFIG_ARCH_PGPOOL_VBASE=0x80600000
CONFIG_ARCH_PGPOOL_SIZE=4194304

## Virtual Memory for NuttX App Code
CONFIG_ARCH_TEXT_VBASE=0xC0000000
CONFIG_ARCH_TEXT_NPAGES=128

## Virtual Memory for NuttX App Data
CONFIG_ARCH_DATA_VBASE=0xC0100000
CONFIG_ARCH_DATA_NPAGES=128

## Virtual Memory for NuttX App Heap
CONFIG_ARCH_HEAP_VBASE=0xC0200000
CONFIG_ARCH_HEAP_NPAGES=128

And here’s the NuttX Linker Script: ld.script

/* TODO: Fix the size */
MEMORY {
  kflash (rx) : ORIGIN = 0x80200000, LENGTH = 2048K   /* w/ cache */
  ksram (rwx) : ORIGIN = 0x80400000, LENGTH = 2048K   /* w/ cache */
  pgram (rwx) : ORIGIN = 0x80600000, LENGTH = 4096K   /* w/ cache */
  ramdisk (rwx) : ORIGIN = 0x80A00000, LENGTH = 16M   /* w/ cache */
}
...
SECTIONS {
  . = 0x80200000;

§14.2 Select the 16550 UART Driver

From OpenSBI Log: We see that SG2000 runs with a 8250 UART Controller.

Thus we select the NuttX Driver for 16550 UART, which is compatible with 8250…

Here’s the NuttX Config: nsh/defconfig

CONFIG_16550_ADDRWIDTH=0
CONFIG_16550_REGINCR=4
CONFIG_16550_UART0=y
CONFIG_16550_UART0_BASE=0x04140000
CONFIG_16550_UART0_CLOCK=23040000
CONFIG_16550_UART0_SERIAL_CONSOLE=y
CONFIG_16550_UART=y
CONFIG_16550_WAIT_LCR=y
CONFIG_SERIAL_UART_ARCH_MMIO=y

Don’t update the NuttX Config File directly! We ran make menuconfig to generate the above file…

## Update NuttX Config
make menuconfig \
  && make savedefconfig \
  && grep -v CONFIG_HOST defconfig \
  >boards/risc-v/bl808/ox64/configs/nsh/defconfig

To Find Menuconfig Settings: Press “/” and enter the name of the setting, like “16550_ADDRWIDTH”. This ensures that the Kconfig Dependencies are correctly updated.

UART IRQ

How did we get IRQ 69 for UART?

We set IRQ 69 for UART0…

That’s because the SG2000 Reference Manual (Page 13) says…

3.1 Interrupt Subsystem

Table 3.2: Interrupt number and Interrupt source mapping for Master RISCV C906 @ 1.0Ghz

Int #44: UART0

Linux Device Tree also says UART0 IRQ is 44 (0x2C)

serial@04140000 {
  compatible = "snps,dw-apb-uart";
  reg = <0x00 0x4140000 0x00 0x1000>;
  clock-frequency = <0x17d7840>;
  reg-shift = <0x02>;
  reg-io-width = <0x04>;
  status = "okay";
  interrupts = <0x2c 0x04>;
  interrupt-parent = <0x04>;
};

Thus we compute NuttX IRQ = 25 + RISC-V IRQ = 69

(We should fix the UART Clock: 16550_UART0_CLOCK)

Whither PLIC?

§14.3 Disable Interrupt Controller

Most RISC-V SBCs (Ox64, Star64) will manage Interrupts with a Platform-Level Interrupt Controller (PLIC). But PLIC isn’t documented for SG2000. (Pic above sigh)

Initially we disable PLIC in NuttX…

Later we’ll dump the SG2000 Linux Device Tree to understand the Interrupt Controller.

§14.4 Dump the Linux Device Tree

To understand the Interrupt Controller: We dump the Linux Device Tree for SG2000.

Based on the SG2000 Debian Image, thanks to Justin Hammond (Fishwaldo)…

We download the Latest Release for Milk-V Duo S (SG2000)…

Then copy out the SG2000 Device Tree Binary: cv181x_milkv_duos_sd.dtb

And convert it to Device Tree Source: cv181x_milkv_duos_sd.dts

## Convert the SG2000 Device Tree
dtc \
  -o cv181x_milkv_duos_sd.dts \
  -O dts \
  -I dtb \
  cv181x_milkv_duos_sd.dtb

We go inside the Device Tree…

§14.5 Interrupt Controller for SG2000

Earlier we dumped the Linux Device Tree for SG2000. We snoop inside to understand the Interrupt Controller: cv181x_milkv_duos_sd.dts

// PLIC Interrupt Controller for External Interrupts
interrupt-controller@70000000 {
  riscv,ndev = <0x65>;
  riscv,max-priority = <0x07>;
  reg-names = "control";
  reg = <0x00 0x70000000 0x00 0x4000000>;
  interrupts-extended = <0x16 0xffffffff 0x16 0x09>;
  interrupt-controller;
  compatible = "riscv,plic0";
  #interrupt-cells = <0x02>;
  #address-cells = <0x00>;
  phandle = <0x04>;
};

// CLINT Interrupt Controller for Internal Interrupts
clint@74000000 {
  interrupts-extended = <0x16 0x03 0x16 0x07>;
  reg = <0x00 0x74000000 0x00 0x10000>;
  compatible = "riscv,clint0";
  clint,has-no-64bit-mmio;
};

We see that PLIC (External Interrupts) is at 0x7000_0000, CLINT (Internal Interrupts) at 0x7400_0000

Platform-Level Interrupt Controller

§14.6 Fix the NuttX Driver for PLIC

Based on the PLIC Address from above: We fix the Platform-Level Interrupt Controller (PLIC) for SG2000…

Now we see a bit more NuttX…

Starting kernel ...
123ABCnx_start: Entry
uart_register: Registering /dev/console
uart_register: Registering /dev/ttyS0
work_start_lowpri: Starting low-priority kernel worker thread(s)
nxtask_activate: lpwork pid=1,TCB=0x80409130
nxtask_activate: AppBringUp pid=2,TCB=0x80409740
nx_start_application: Starting init task: /system/bin/init
elf_symname: Symbol has no name
elf_symvalue: SHN_UNDEF: Failed to get symbol name: -3
elf_relocateadd: Section 2 reloc 2: Undefined symbol[0] has no name: -3
nxtask_activate: /system/bin/init pid=3,TCB=0x8040b730
nxtask_exit: AppBringUp pid=2,TCB=0x80409740

Nuttnx_start: CPU0: Beginning Idle Loop

(See the Complete Log)

Why did it stop?

Duh we set the wrong UART0 IRQ! Here’s the fix…

§14.7 Enable Logging for Scheduler

For easier troubleshooting: We enable Logging for NuttX Scheduler and Binary Loader

Here’s the NuttX Config: nsh/defconfig

CONFIG_DEBUG_BINFMT=y
CONFIG_DEBUG_BINFMT_ERROR=y
CONFIG_DEBUG_BINFMT_WARN=y
CONFIG_DEBUG_SCHED=y
CONFIG_DEBUG_SCHED_ERROR=y
CONFIG_DEBUG_SCHED_INFO=y
CONFIG_DEBUG_SCHED_WARN=y

Remember: Always use make menuconfig to update the settings!

§14.8 NuttX Crash Dump

What happens when something goes wrong in NuttX?

We’ll see a NuttX Crash Dump, like so…

Booting using the fdt blob at 0x81200000
Loading Ramdisk to 9fe00000, end 9fe00000 ... OK
Loading Device Tree to 000000009f26f000, end 000000009f27e43a ... OK
Starting kernel ...

123ABCnx_start: Entry
uart_register: Registering /dev/console
uart_register: Registering /dev/ttyS0
work_start_lowpri: Starting low-priority kernel worker thread(s)
nxtask_activate: lpwork pid=1,TCB=0x80408130
nxtask_activate: AppBringUp pid=2,TCB=0x80408740
nx_start_application: Starting init task: /system/bin/init
elf_symname: Symbol has no name
elf_symvalue: SHN_UNDEF: Failed to get symbol name: -3
elf_relocateadd: Section 2 reloc 2: Undefined symbol[0] has no name: -3

_assert: Current Version: NuttX  12.4.0 f37a380-dirty May  7 2024 10:31:33 risc-v
_assert: Assertion failed 0x17 == (insn & 0x7F): at file: machine/risc-v/arch_elf.c:494 task: AppBringUp process: Kernel 0x80200f34
up_dump_register: EPC: 000000008021087a
up_dump_register: A0: 0000000080401b70 A1: 00000000000001ee A2: 0000000080228ef8 A3: 0000000000000000
up_dump_register: A4: 0000000000000017 A5: 0000000000000002 A6: 000000000000ab9c A7: fffffffffffffff8
up_dump_register: T0: 000000000000002e T1: 0000000000000007 T2: 00000000000001ff T3: 000000008040c3fc
up_dump_register: T4: 000000008040c3f0 T5: 0000000000000009 T6: 000000000000002a
up_dump_register: S0: 0000000000000000 S1: 0000000080408740 S2: 0000000000000017 S3: 0000000000000000
up_dump_register: S4: 0000000080228ef8 S5: 0000000080228de8 S6: 0000000080401e10 S7: 8000000201842022
up_dump_register: S8: 00000000000001ee S9: 000000008040b9a0 S10: 0000000000000070 S11: 000000008040b990
up_dump_register: SP: 000000008040c330 FP: 0000000000000000 TP: 0000000000000000 RA: 000000008021087a
dump_stack: User Stack:
dump_stack:   base: 0x8040c030
dump_stack:   size: 00002000
dump_stack:     sp: 0x8040c330

(See the Complete Log)

What’s this Assertion Failure?

_assert: Assertion failed 0x17 == (insn & 0x7F):
at file: machine/risc-v/arch_elf.c:494
task: AppBringUp process: Kernel 0x80200f34

Oops we goofed and used the Wrong U-Boot Command

## Nope! This won't work for NuttX. RAM Disk Address must be `-`!
setenv tftp_server 192.168.31.10 ; dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000 ;
tftpboot ${fdt_addr_r} ${tftp_server}:cv181x_milkv_duos_sd.dtb ; fdt addr ${fdt_addr_r} ;
booti ${kernel_addr_r} ${ramdisk_addr_r}:${ramdisk_size} ${fdt_addr_r}

Which overwrites the NuttX Image in RAM. Here’s the Correct U-Boot Command

## This works OK for NuttX. RAM Disk Address must be `-`!
setenv tftp_server 192.168.31.10 ; dhcp ${kernel_addr_r} ${tftp_server}:Image-sg2000 ;
tftpboot ${fdt_addr_r} ${tftp_server}:cv181x_milkv_duos_sd.dtb ; fdt addr ${fdt_addr_r} ; 
booti ${kernel_addr_r} - ${fdt_addr_r}

Calculus with Julia

jverzani.github.io - Comments

logo.png

Calculus with Julia

This is a set of notes for learning calculus using the Julia language. Julia is an open-source programming language with an easy to learn syntax that is well suited for this task.

Read “Getting started with Julia” to learn how to install and customize Julia for following along with these notes. Read “Julia interfaces to review different ways to interact with a Julia installation.

Since the mid 90s there has been a push to teach calculus using many different points of view. The Harvard style rule of four says that as much as possible the conversation should include a graphical, numerical, algebraic, and verbal component. These notes use the programming language Julia to illustrate the graphical, numerical, and, at times, the algebraic aspects of calculus.

There are many examples of integrating a computer algebra system (such as Mathematica, Maple, or Sage) into the calculus conversation. Computer algebra systems can be magical. The popular WolframAlpha website calls the full power of Mathematica while allowing an informal syntax that is flexible enough to be used as a backend for Apple’s Siri feature. (“Siri what is the graph of x squared minus 4?”) For learning purposes, computer algebra systems model very well the algebraic/symbolic treatment of the material while providing means to illustrate the numeric aspects. These notes are a bit different in that Julia is primarily used for the numeric style of computing and the algebraic/symbolic treatment is added on. Doing the symbolic treatment by hand can be very beneficial while learning, and computer algebra systems make those exercises seem kind of redundant, as the finished product can be produced much easier.

Our real goal is to get at the concepts using technology as much as possible without getting bogged down in the mechanics of the computer language. We feel Julia has a very natural syntax that makes the initial start up not so much more difficult than using a calculator, but with a language that has a tremendous upside. The notes restrict themselves to a reduced set of computational concepts. This set is sufficient for working many of the problems in calculus, but do not cover thoroughly many aspects of programming. (Those who are interested can go off on their own and Julia provides a rich opportunity to do so.) Within this restricted set, are operators that make many of the computations of calculus reduce to a function call of the form action(function, arguments...). With a small collection of actions that can be composed, many of the problems associated with introductory calculus can be attacked.

These notes are presented in pages covering a fairly focused concept, in a spirit similar to a section of a book. Just like a book, there are try-it-yourself questions at the end of each page. All have a limited number of self-graded answers. These notes borrow ideas from many sources, for example Strang (n.d.), Knill (n.d.), Schey (1997), Hass, Heil, and Weir (2018), Rogawski, Adams, and Franzosa (2019), several Wikipedia pages, and other sources..

These notes are accompanied by a Julia package CalculusWithJulia that provides some simple functions to streamline some common tasks and loads some useful packages that will be used repeatedly.

These notes are presented as a Quarto book. To learn more about Quarto books visit https://quarto.org/docs/books.

These notes may be compiled into a pdf file through Quarto. As the result is rather large, we do not provide that file for download. For the interested reader, downloading the repository, instantiating the environment, and running quarto to render to pdf in the quarto subdirectory should produce that file (after some time).

To contribute – say by suggesting addition topics, correcting a mistake, or fixing a typo – click the “Edit this page” link and join the list of contributors. Thanks to all contributors and a very special thanks to @fangliu-tju for their careful and most-appreciated proofreading.


Calculus with Julia version 0.18, produced on April 26, 2024.

Hass, Joel R., Christopher E. Heil, and Maurice D. Weir. 2018. Thomas’ Calculus. Pearson.

Knill, Oliver. n.d. “Some Teaching Notes.” https://people.math.harvard.edu/~knill/teach/index.html.

Rogawski, Jon, Colin Adams, and Robert Franzosa. 2019. Calculus. Macmillan.

Schey, H. M. 1997. Div, Grad, Curl, and All That. W.W. Norton.

Strang, Gilbert. n.d. “Calculus.” Wellesley-Cambridge Press. https://ocw.mit.edu/courses/res-18-001-calculus-online-textbook-spring-2005/.

Floor796

floor796.com - Comments

Show HN: A Golang CP/M emulator

github.com - Comments

Golang CP/M emulator for playing zork, lighthouse-of-doom, etc

License

Additional navigation options

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Footer

You can’t perform that action at this time.

Sam and Greg's response to OpenAI Safety researcher claims

twitter.com - Comments

I Couldn't Escape Poison Oak. So I Started Eating It

www.wsj.com - Comments

YARA is dead, long live YARA-X

virustotal.github.io - Comments

For over 15 years, YARA has been growing and evolving until it became an indispensable tool in every malware researcher’s toolbox. Throughout this time YARA has seen numerous updates, with new features added and countless bugs fixed. But today, I’m excited to announce the biggest change yet: a full rewrite.

YARA-X is a completely new implementation of YARA in Rust, and it has the following goals:

  • Better user experience: The new command-line interface is more modern and colorful, and error reports are now more explicative. More features aimed at improving the user’s experience will be incorporated in the future.

  • Rule-level compatibility: While achieving 100% compatibility is tough, our aim is to make YARA-X 99% compatible with YARA at the rule level. Incompatibilities should be minimal and thoroughly documented.

  • Improved performance: YARA is known for its speed, but certain rules, especially those utilizing regular expressions or complex loops, can slow it down. YARA-X excels with these rules, often delivering significantly faster results. Our ultimate goal is for YARA-X to outperform YARA across the board.

  • Enhanced reliability and security: YARA’s complexity in C code can lead to bugs and security vulnerabilities. YARA-X is built with Rust, offering greater reliability and security.

  • Developer-friendly: We’re prioritizing ease of integration into other projects and simplified maintenance. Official APIs for Python, Golang, and C are provided to facilitate seamless integration. YARA-X also addresses some of the design flaws that made YARA challenging to maintain and extend.

Why a rewrite?

Was a complete rewrite necessary to achieve such goals? This question lingered in my mind for a long time before deciding to rewrite YARA. Rewriting is risky, it introduces new bugs, backward compatibility issues, and doubles the maintenance efforts, since legacy code doesn’t disappear after launching the new system. In fact, the legacy system may be still in use for years, if not decades.

However, I believe a rewrite was the right decision for multiple reasons:

  • YARA is not a large project, it’s a medium-size project that lacks subsystems or components large enough to be migrated in isolation. Incremental migration to Rust was impractical because large portions of the code are interconnected.

  • The improvements I envisioned required significant design changes. Implementing these in the existing C codebase would involve extensive rewrites, carrying the same risks as starting fresh with Rust.

  • After a year of working on the project, I’ve found Rust easier to maintain than C. Rust offers stronger reliability guarantees and simplifies integrating third-party code, especially for multi-platform projects.

Is YARA really dead?

Despite the dramatic title of this post, YARA is not actually dead. I’m aware that many people and organizations rely on YARA to get important work done, and I don’t want to let them down.

YARA is still being maintained, and future releases will include bug fixes and minor features. However, don’t expect new large features or modules. All efforts to enhance YARA, including the addition of new modules, will now focus on YARA-X.

What’s the current state of YARA-X?

YARA-X is still in beta, but is mature and stable enough for use, specially from the command-line interface or one-shot Python scripts. While the APIs may still undergo minor changes, the foundational aspects are already established.

At VirusTotal, we have been running YARA-X alongside YARA for a while, scanning millions of files with tens of thousands of rules, and addressing discrepancies between the two. This means that YARA-X is already battle-tested. These tests have even uncovered YARA bugs!

Please test YARA-X and don’t hesitate to open an issue if you find a bug or some feature that you want to see implemented.

What’s next?

My aim is to surpass YARA in every possible aspect with YARA-X. I want it to be so superior that existing YARA users willingly migrate to YARA-X for its undeniable advantages, not because they are forced to do so.

Publishing a beta version is only the first step towards this goal. I’ll continue to enhance YARA-X, releasing updates and sharing insights through blog posts like this one.

Stay tuned, because this journey has only just begun.

A kids traffic mat in Elm

matiasklemola.com - Comments

Liikennematto is a tiny simulation game for children and grown-ups alike. The gameplay is simple: you only build the roads! Lots, buildings and their residents pop up after.

I used to keep a somewhat regular devlog for Liikennematto. The previous entries appeared 6-12 months apart, but since July 2021 the devlog has been on pause. I didn't stop working on the game, though (in fact the time I could have spent writing devlogs went to development instead). This belated entry then sums up nearly 3 years of development!

Last time I described Liikennematto's transformation to a real-time traffic simulation. Here's where I left you.

Liikennematto circa mid-2021

New visuals and sounds

I prototyped Liikennematto using premade assets from Kenney and some crude lot placeholders of my own. In 2022 I completely overhauled the assets. I spent a lot of time on selecting a bright and lively palette that works with the children's traffic mat metaphor.

Inspired by the traffic mat art style, I've drawn buildings and objects in various perspectives. Some of them are fake 3D and some are just flat sprites. The cars and roads follow a top-down perspective for simplicity's sake.

The trees, flowers and other organic objects are hand-drawn and traced to vector format. Buildings, roads and cars are digital vector drawings. I like the contrast between geometric man-made structures and the free-flowing nature.

I started with some obvious lots (school, café, fire station, low and high density residential). I intend to keep the lots unique, so that they only appear once. Car models and decorations re-appear in various colors.

Liikennematto gameplay in 2024

I've used Figma as the vector drawing tool. Game asset creation is not really what Figma is usually used for, but I'm familiar with the app from work and it gets the job done. The biggest drawback is a lack of a gamedev-specific asset pipeline. I have a manual process where I adjust the SVG content to work with the game. With a low amount of assets it works, despite the labor. Maybe I'll automate the process later.

I also added some sound effects. For instance, placing a road tile triggers a sound that reinforces the action. A bit later a slightly higher pitched version of the sound plays when the road has been built. Both sounds are synced with the animation. Sound effects have a playful marimba-like timbre that complements the visuals. I've created the sounds using Ableton Live. I intend to add some light music to the game later.

UI overhaul

Liikennematto doesn't need much of an UI for the core gameplay in terms of panels and widgets. Most of the UI consists of debug tools and controls for starting a new game. The previous placeholder UI with emoji icons is gone. I've drawn custom icons for the UI and added a zoom control with three levels. The UI follows the palette of the game graphics.

I spent a good while making Liikennematto fun to play on touch devices and various screen sizes. You can now effortlessly pan and zoom around the tilemap. You can build roads with a click or tap, and remove them with a right-click or long press. The latter wasn't trivial to get right, as there's a fine line between swiping and tapping the screen. The action is triggered after a small delay and is visualized with a progress bar. Once the progress bar is full, releasing the long press will remove the road tile.

Parking

Possibly the biggest new feature since 2021 is the fully-featured parking system. Lots come with parking areas that have one or more parking spots. For each spot, I've defined a path to the lot entrance using a "parking lane" that influences the curve of the path. The paths vary a lot, since parking areas have different sizes and orientations. This path connects to the road network graph, where the car's route truly begins.

I didn't want the lots to be huge and neither are the parking areas. With the limited space, only one car may (un)park at a time. The lots have a parking lock that enforces the rule. While a car is moving in the parking area, the lock remains. Any other car willing to unpark or enter the lot will have to wait for their turn. Parking in the tiny areas is pretty fast, so the queue doesn't grow too long.

Some parking spots are reserved for the lot residents, or because of the role of a vehicle (a spot for a fire truck at a fire station). The residents prefer these spots, leaving free spots for guests.

Getting all of this to work was satisfying. I built new debug tools to visualize the state of the parking area, which was time well spent, because it revealed subtle bugs in the system.

Parking in action, with the parking debug overlay

A* pathfinding

Liikennematto has a road network graph built from the road tiles. The graph is used for routing cars around the map. The original routing algorithm simply started from a point in the graph (like an intersection entry) and navigated the graph using random directions from nodes until the route was long enough. This resulted in completely random routes with no sensible goal.

Now the routes are generated with the standard A* pathfinding algorithm, which finds a short path from a graph node to another node using distance to the goal as a heuristic. I looked up an example of the algorithm in Python and manually translated it into functional Elm code. With the small maps of Liikennematto, my optimised Elm implementation of the A* is capable of creating ~18 000 routes per second on an average machine using just one thread. That's fast enough to allow dynamic rerouting of cars on tilemap change. For example, a car that is waiting for a green traffic light may turn into a different direction from the intersection that it was about to just milliseconds before! It's fun to watch the routes adjust to the updated tilemap.

The most common route is from one lot to another lot. Sometimes the cars choose to just enjoy a short drive with no destination.

Game architecture and data flow

The Liikennematto codebase has grown over time. When I started out, I didn't have a clear plan for the game architecture. Now that I can see what the main parts are, I've refactored the Elm modules into four namespaces; Tilemap, Simulation, Render and UI.

This follows the way things build on top of each other:

  • the tilemap is the base that the simulation runs on
  • the simulation works with the road network graph, and listens to tilemap changes to (re)build it
  • the tilemap and simulated entities, like cars, are then rendered separately
  • on top of all of that, the UI triggers tilemap changes and enables debug tools

With this separation of concerns the code modules found their natural place. The namespaces interact via two interfaces: the Elm event loop and the World module, which contains the game state. Render and UI only read from the World interface, while Simulation and Tilemap may update it as well.

liikennematto_architecture_2024.pngLiikennematto game architecture. Grey blue denotes interface, bright blue denotes namescape

The data flow inside the tilemap and simulation layers has changed as well. There's a lot of state to keep track of, and entities go through various state changes. Updates to the tilemap and entities have side-effects (sounds, re/despawn, rebuilding of lookup data structures, etc.).

The Elm Architecture and its event based updates help to some extent, yet I've implemented a custom event queue for fine-grained control of the data flow. The simulation and tilemap update process accumulate events that are then flushed once per frame to change things instantly (for later steps in the update flow), or scheduled for later.

Some examples of delayed events include cars spawning on lots and updates to car paths when the road network changes. The delay is also used to spread events over time to add some randomness to the simulation. Sometimes an event cannot be processed with the current state of the simulation. The custom event queue allows retry and if enough retries fail, the event may be discarded and a recovery strategy might then despawn related entities.

I also built a finite state machine (FSM) library to formally specify how cars, traffic lights, tiles and even the game initialization phase transition from a state to another. I included some ideas from AI for Games, Third Edition, notably entry and exit actions for a state. FSMs are the backbone of many programs and games, because of their utility. Without FSM states and transitions are hidden, often accidental. Having a clear spec for these removes a whole class of potential bugs. In Liikennematto they also help to sync animations and sounds to key actions.

Itch.io release

In November 2022 most of the changes were in place. Considering the small scope of the game, core features work well and what's missing is content. I decided then that it's time to release the game to early access. itch.io felt like a good place for that. Many fledging game developers use itch.io to preview and ship their games. itch.io is especially nice for games that can be played in a browser, like Liikennematto.

The release was a tiny success. In the first few months the game was played over 500 times and many itch.io users added the game to their collections. I also received positive feedback from the users.

In March 2023 I released a patch that added some variety to the content and improved the simulation. Around that time I also composed a review of the first three years of Liikennematto development in the form of the video below.

The future

Since early 2023 the development has slowed down quite a bit.

The last 12 months have been tough for me. Work became very stressful and I eventually changed jobs, for the better. In late 2023 I lost a friend to cancer, and recently another to a rare disease. I've been exhausted and I have grieved.

Hobby game development has offered me a way to channel my creative impulses to and escape from the negative aspects of daily life. Now I often have the time but not the energy for it. Our family is also about to grow, which itself is a wonderful thing, but the time for hobbies might become scarce. For this reason updates to Liikennematto have no timeline. Whatever time it may take, I still want to keep on developing Liikennematto to fulfill the vision that I have.

...

The next item on the roadmap is improved procedural generation of the lots and decorations. Despite slow and interrupted development, I've made some progress in implementing wave function collapse (WFC), a popular algorithm that fills a (portion of a) map with shapes that conform to constraints. With a tilemap-based game like Liikennematto, this means that each tile has multiple options (superposition) that might fit. When a tile option is picked (collapsed), the neighbor tiles' options are reduced to the point that the map resolves itself after several steps. WFC is often compared to sudoku, which has a similar solving process.

I've implemented complete map generation with multi-tile shapes and error handling. I'm now in the process of integrating WFC into the gameplay to achieve "driven WFC" - the player's decisions (road placement) drive the generation. This is quite a bit harder than generating maps without the player's input. Let's see how it goes - and how long it takes.

Here's a peek into WFC for Liikennematto:

In the meantime, you can play the most recent version of Liikennematto over at itch.io.

Next development updates and release announcements will be released on itch.io, marking this as the last devlog on this site. You can follow me on Mastodon for updates inbetween.

Liikennematto Github repository

Retrospex: Convert images to fit Commodore 64 graphic modes

github.com - Comments

Convert images to fit Commodore 64 graphic modes

Additional navigation options

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Footer

You can’t perform that action at this time.

500-year-old maths problem turns out to apply to coffee and clocks

www.newscientist.com - Comments

Mathematics

A centuries-old maths problem asks what shape a circle traces out as it rolls along a line. The answer, dubbed a “cycloid”, turns out to have applications in a variety of scientific fields

By Sarah Hart

Light reflecting off the round rim creates a mathematically significant shape in this coffee cup

Sarah Hart

The following is an extract from our Lost in Space-Time newsletter. Each month, we hand over the keyboard to a physicist or mathematician to tell you about fascinating ideas from their corner of the universe. You can sign up for Lost in Space-Time for free here.

The artist Paul Klee famously described drawing as “taking a line for a walk” – but why stop there? Mathematicians have been wondering for five centuries what happens when…