< January 2022
MonTueWedThuFriSatSun
27282930310102
03040506070809
10111213141516
17181920212223
24252627282930
31010203040506

Thursday, 06 January 2022

09:14 PM

Opening Files Quickly from Inside vim [blogs.perl.org] 09:14 PM, Thursday, 06 January 2022 04:20 PM, Thursday, 06 January 2022

I use ot a lot when it comes to opening files. I wanted to be able to use this tool from inside vim as well. It turns out, the solution is quite simple.

Full post: https://www.olafalders.com/2022/01/05/open-this-file-from-inside-vim/


04:40 PM

Writing a SNES assembler compiler/disassembler - Day 4 [blogs.perl.org] 04:40 PM, Thursday, 06 January 2022 12:00 PM, Thursday, 06 January 2022

Testing

It's time to test what we have written so far. If you look at the asar project, there are already some test files and they come with their own test syntax. It's actually pretty neat since it's embedded in the ASM files comments, so you don't need to write specific tests files.

The format is documented here https://github.com/RPGHacker/asar#test-format but for now, we will just keep the offset and byte value part.

Testing grammar

We could write a loop with like files.IO.slurp.lines and be done to handle this. But let use again a grammar. No action associated with it since it's very basic.

grammar Test-File { token TOP { <thing>+ } token thing { || <test-line> <.eol> || <other> <.eol> } token test-line { ';`' (<offset> | <byte>) (<.ws> <byte>)* { %test-data-array{$offset}[$pos-tab] = $dataas; $dataas = buf8.new; $pos-tab++; } } token byte { $<value> = (<xdigit><xdigit>) { %test-data{$offset}.append($<value>.Str.parse-base(16)); $dataas.append($<value>.Str.parse-base(16)); } } token offset { $<value> = <xdigit> ** 5..6 { $offset = $<value>.Str.parse-base(16); %test-data{$offset} = buf8.new; } } token other { <-[\n]>* } ... }
 

We fill 2 hashes. One is just a pairing of offset => all bytes for this offset the other is a table used for my own tests where we have only 1 instruction per line and one line of bytes corresponding to the instruction. It makes finding bad assembly errors easier to spot since I can test each instruction with its own assembling.

15: ;`71 35 16: ADC ($37), Y skarsnik@DESKTOP-UIA12T1:/mnt/f/Project/SnesASM$ raku -I lib bin/test-snes-asm.raku t/asm/04-all-instruction.asm Data stopped matching at line 16 for : ADC ($37), Y expected :Buf[uint8]:0x<71 35> got :Buf[uint8]:0x<71 37> Test data does not match
 

Generating a test file

I generated a file with the 255 instructions supported by the snes cpu asm and manually fill the expected bytecode. It was not perfect but it was still very useful to fix a lot of errors in the sub that generate the operand text.

The file looks like this

;`61 D2 ADC ($D2, X) ;`63 F2 ADC $F2, S ;`65 85 ADC $85 ;`67 A5 ADC [$A5] ;`69 F3
 

Starting to test...

And then immediately having to fix the ASM grammar. First, let's add a very basic error handling at the TOP token

token TOP { :my Int $*line-number = 1; (<.eol>* <thing>+ <.ws> <eol>* $) || <.error> } ... token eol { $<lines> = \n[\h*\n]* { $*line-number += $<lines>.lines.elems; } } method error { say "Error parsing the ASM: Error at line: ", $*line-number; exit 1; } }
 

This will probably need to throw later to be propagated.

Ordering issue

If you look at the first few line of the file and the way my instruction tokens are made you can maybe notice an issue with this:

;`63 F2 ADC $F2, S
 

If you don't see it, remember that you can write ADC $42 that is matched by token instruction:sym<ADC-DIRECT-PAGE> {:i "ADC"<.ws><DIRECT-PAGE>} Raku grammar engine does not backtrack much, so seeing ADC $F2, S the grammar matched a <ADC-DIRECT-PAGE> then when trying to continue the match for the <one-instruction>, it fails because , fit nothing. It will then try <instruction-line> and again match for <ADC-DIRECT-PAGE> and again can't make sense of the , and stop. (Thank the Grammar::Tracer module in Grammar::Debugger to see that)

There is a simple fix for that if you have an issue like that in your grammar: order your match with ||. But I would need to write something like token instruction-adc {<adc-stack-relative> || <adc-direct-page>} and since I did not want to manually write all the instruction grammar, I choose to define an end of instruction token and use the <?before> keyword that allows defining what is supposed to come after what you want to match.

The changed instruction grammar looks like this :

token eoi { <.ws> [\n | ';' | ':' | $] } proto token instruction {*} token instruction:sym<ADC-DP-INDEXED-INDIRECT-X> {:i "ADC"<.ws><DP-INDEXED-INDIRECT-X> <?before <eoi>>} token instruction:sym<ADC-STACK-RELATIVE> {:i "ADC"<.ws><STACK-RELATIVE> <?before <eoi>>} token instruction:sym<ADC-DIRECT-PAGE> {:i "ADC"<.ws><DIRECT-PAGE> <?before <eoi>>} ...
 

Finalizing

I had to tweak some instruction. The COP and BRK instruction can optionally take a byte operand to identify them, It was mostly a matter of changing the <STACK-RELATIVE> token in the addressing grammar and provide a default value when no byte is specified.

I also have all the instructions taking a <IMMEDIATE> addressing to fix, since the Accumulator and the 2 registers X/Y can work on 8 or 16 bits mode (depends on the CPU flags), LDA #$42 and LDA #$4269 are valid. But LDA #$42 alone is ambiguous, you could assemble it into A9 42 00 or A9 42. I will fix this later and add disambiguous instruction like asar choose to do, eg: LDA.w and LDA.b. For now, they only accept a byte

Let's run the test one last time :

skarsnik@DESKTOP-UIA12T1:/mnt/f/Project/SnesASM$ raku -I lib bin/test-snes-asm.raku t/asm/04-all-instruction.asm Compiled : 257 instructions Compiled succefully
 

Note that there are 257 instructions since there is both version for COP and BRK

Not bad, but we will need things like labels support to have a usable assembler :)

02:32 PM

Eva Wentink’s Self-Monitoring Toilet Musings (local copy) [] 02:32 PM, Thursday, 06 January 2022 10:40 PM, Monday, 17 January 2022

Eva Wentink from OnePlanet (an institute created in a partnership of Wageningen University and Research, Radboud University Nijmegen and IMEC) muses, low-key charismatically, about the need and feasibility of a self-monitoring toilet. She explains how and why she and her colleagues built three toilets:

(Thanks to Michiel Scheffer for bringing this to our attention.)

12:00 AM

Jacob Adams: Linux Hibernation Documentation [Planet Debian] 12:00 AM, Thursday, 06 January 2022 03:20 AM, Friday, 07 January 2022

Recently I’ve been curious about how hibernation works on Linux, as it’s an interesting interaction between hardware and software. There are some notes in the Arch wiki and the kernel documentation (as well as some kernel documentation on debugging hibernation and on sleep states more generally), and of course the ACPI Specification

The Formal Definition

ACPI (Advanced Configuration and Power Interface) is, according to the spec, “an architecture-independent power management and configuration framework that forms a subsystem within the host OS” which defines “a hardware register set to define power states.”

ACPI defines four global system states G0, working/on, G1, sleeping, G2, soft off, and G3, mechanical off1. Within G1 there are 4 sleep states, numbered S1 through S4. There are also S0 and S5, which are equivalent to G0 and G2 respectively2.

Sleep

According to the spec, the ACPI S1-S4 states all do the same thing from the operating system’s perspective, but each saves progressively more power, so the operating system is expected to pick the deepest of these states when entering sleep. However, most operating systems3 distinguish between S1-S3, which are typically referred to as sleep or suspend, and S4, which is typically referred to as hibernation.

S1: CPU Stop and Cache Wipe

The CPU caches are wiped and then the CPU is stopped, which the spec notes is equivalent to the WBINVD instruction followed by the STPCLK signal on x86. However, nothing is powered off.

S2: Processor Power off

The system stops the processor and most system clocks (except the real time clock), then powers off the processor. Upon waking, the processor will not continue what it was doing before, but instead use its reset vector4.

S3: Suspend/Sleep (Suspend-to-RAM)

Mostly equivalent to S2, but hardware ensures that only memory and whatever other hardware memory requires are powered.

S4: Hibernate (Suspend-to-Disk)

In this state, all hardware is completely powered off and an image of the system is written to disk, to be restored from upon reapplying power. Writing the system image to disk can be handled by the operating system if supported, or by the firmware.

Linux Sleep States

Linux has its own set of sleep states which mostly correspond with ACPI states.

Suspend-to-Idle

This is a software only sleep that puts all hardware into the lowest power state it can, suspends timekeeping, and freezes userspace processes.

All userspace and some kernel threads5, except those tagged with PF_NOFREEZE, are frozen before the system enters a sleep state. Frozen tasks are sent to the __refrigerator(), where they set TASK_UNINTERRUPTIBLE and PF_FROZEN and infinitely loop until PF_FROZEN is unset6.

This prevents these tasks from doing anything during the imaging process. Any userspace process running on a different CPU while the kernel is trying to create a memory image would cause havoc. This is also done because any filesystem changes made during this would be lost and could cause the filesystem and its related in-memory structures to become inconsistent. Also, creating a hibernation image requires about 50% of memory free, so no tasks should be allocating memory, which freezing also prevents.

Standby

This is equivalent to ACPI S1.

Suspend-to-RAM

This is equivalent to ACPI S3.

Hibernation

Hibernation is mostly equivalent to ACPI S4 but does not require S4, only requiring “low-level code for resuming the system to be present for the underlying CPU architecture” according to the Linux sleep state docs.

To hibernate, everything is stopped and the kernel takes a snapshot of memory. Then, the system writes out the memory image to disk. Finally, the system either enters S4 or turns off completely.

When the system restores power it boots a new kernel, which looks for a hibernation image and loads it into memory. It then overwrites itself with the hibernation image and jumps to a resume area of the original kernel7. The resumed kernel restores the system to its previous state and resumes all processes.

Hybrid Suspend

Hybrid suspend does not correspond to an official ACPI state, but instead is effectively a combination of S3 and S4. The system writes out a hibernation image, but then enters suspend-to-RAM. If the system wakes up from suspend it will discard the hibernation image, but if the system loses power it can safely restore from the hibernation image.

  1. The difference between soft and mechanical off is that mechanical off is “entered and left by a mechanical means (for example, turning off the system’s power through the movement of a large red switch)” 

  2. It’s unclear to me why G and S states overlap like this. I assume this is a relic of an older spec that only had S states, but I have not as yet found any evidence of this. If someone has any information on this, please let me know and I’ll update this footnote. 

  3. Of the operating systems I know of that support ACPI sleep states (I checked Windows, Mac, Linux, and the three BSDs8), only MacOS does not allow the user to deliberately enable hibernation, instead supporting a hybrid suspend it calls safe sleep 

  4. “The reset vector of a processor is the default location where, upon a reset, the processor will go to find the first instruction to execute. In other words, the reset vector is a pointer or address where the processor should always begin its execution. This first instruction typically branches to the system initialization code.” Xiaocong Fan, Real-Time Embedded Systems, 2015 

  5. All kernel threads are tagged with PF_NOFREEZE by default, so they must specifically opt-in to task freezing. 

  6. This is not from the docs, but from kernel/freezer.c which also notes “Refrigerator is place where frozen processes are stored :-).” 

  7. This is the operation that requires “special architecture-specific low-level code”. 

  8. Interestingly NetBSD has a setting to enable hibernation, but does not actually support hibernation 

Feeds

FeedRSSLast fetchedNext fetched after
XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Bits of DNA XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
blogs.perl.org XML 12:00 AM, Tuesday, 18 January 2022 12:15 AM, Tuesday, 18 January 2022
Blue Collar Bioinformatics XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Boing Boing XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Epistasis Blog XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Futility Closet XML 12:00 AM, Tuesday, 18 January 2022 12:15 AM, Tuesday, 18 January 2022
gCaptain XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Hackaday XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
In between lines of code XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
InciWeb Incidents for California XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
LeafSpring XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Living in an Ivory Basement XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
LWN.net XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Mastering Emacs XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Planet Debian XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Planet Emacsen XML 12:00 AM, Tuesday, 18 January 2022 12:15 AM, Tuesday, 18 January 2022
RNA-Seq Blog XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
RStudio Blog - Latest Comments XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
RWeekly.org - Blogs to Learn R from the Community XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
The Adventure Blog XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
The Allium XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
Variance Explained XML 12:00 AM, Tuesday, 18 January 2022 12:30 AM, Tuesday, 18 January 2022
January 2022
MonTueWedThuFriSatSun
27282930310102
03040506070809
10111213141516
17181920212223
24252627282930
31010203040506
December 2021
MonTueWedThuFriSatSun
29300102030405
06070809101112
13141516171819
20212223242526
27282930310102
November 2021
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29300102030405
October 2021
MonTueWedThuFriSatSun
27282930010203
04050607080910
11121314151617
18192021222324
25262728293031
September 2021
MonTueWedThuFriSatSun
30310102030405
06070809101112
13141516171819
20212223242526
27282930010203
August 2021
MonTueWedThuFriSatSun
26272829303101
02030405060708
09101112131415
16171819202122
23242526272829
30310102030405
July 2021
MonTueWedThuFriSatSun
28293001020304
05060708091011
12131415161718
19202122232425
26272829303101
June 2021
MonTueWedThuFriSatSun
31010203040506
07080910111213
14151617181920
21222324252627
28293001020304
May 2021
MonTueWedThuFriSatSun
26272829300102
03040506070809
10111213141516
17181920212223
24252627282930
31010203040506
April 2021
MonTueWedThuFriSatSun
29303101020304
05060708091011
12131415161718
19202122232425
26272829300102
March 2021
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29303101020304
February 2021
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
November 2020
MonTueWedThuFriSatSun
26272829303101
02030405060708
09101112131415
16171819202122
23242526272829
30010203040506
September 2020
MonTueWedThuFriSatSun
31010203040506
07080910111213
14151617181920
21222324252627
28293001020304
July 2020
MonTueWedThuFriSatSun
29300102030405
06070809101112
13141516171819
20212223242526
27282930310102
June 2020
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29300102030405
May 2020
MonTueWedThuFriSatSun
27282930010203
04050607080910
11121314151617
18192021222324
25262728293031
April 2020
MonTueWedThuFriSatSun
30310102030405
06070809101112
13141516171819
20212223242526
27282930010203
February 2020
MonTueWedThuFriSatSun
27282930310102
03040506070809
10111213141516
17181920212223
24252627282901
January 2020
MonTueWedThuFriSatSun
30310102030405
06070809101112
13141516171819
20212223242526
27282930310102
December 2019
MonTueWedThuFriSatSun
25262728293001
02030405060708
09101112131415
16171819202122
23242526272829
30310102030405
November 2019
MonTueWedThuFriSatSun
28293031010203
04050607080910
11121314151617
18192021222324
25262728293001
October 2019
MonTueWedThuFriSatSun
30010203040506
07080910111213
14151617181920
21222324252627
28293031010203
August 2019
MonTueWedThuFriSatSun
29303101020304
05060708091011
12131415161718
19202122232425
26272829303101
July 2019
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29303101020304
June 2019
MonTueWedThuFriSatSun
27282930310102
03040506070809
10111213141516
17181920212223
24252627282930
May 2019
MonTueWedThuFriSatSun
29300102030405
06070809101112
13141516171819
20212223242526
27282930310102
April 2019
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29300102030405
March 2019
MonTueWedThuFriSatSun
25262728010203
04050607080910
11121314151617
18192021222324
25262728293031
February 2019
MonTueWedThuFriSatSun
28293031010203
04050607080910
11121314151617
18192021222324
25262728010203
January 2019
MonTueWedThuFriSatSun
31010203040506
07080910111213
14151617181920
21222324252627
28293031010203
December 2018
MonTueWedThuFriSatSun
26272829300102
03040506070809
10111213141516
17181920212223
24252627282930
31010203040506
November 2018
MonTueWedThuFriSatSun
29303101020304
05060708091011
12131415161718
19202122232425
26272829300102
October 2018
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29303101020304
September 2018
MonTueWedThuFriSatSun
27282930310102
03040506070809
10111213141516
17181920212223
24252627282930
August 2018
MonTueWedThuFriSatSun
30310102030405
06070809101112
13141516171819
20212223242526
27282930310102
July 2018
MonTueWedThuFriSatSun
25262728293001
02030405060708
09101112131415
16171819202122
23242526272829
30310102030405
June 2018
MonTueWedThuFriSatSun
28293031010203
04050607080910
11121314151617
18192021222324
25262728293001
May 2018
MonTueWedThuFriSatSun
30010203040506
07080910111213
14151617181920
21222324252627
28293031010203
April 2018
MonTueWedThuFriSatSun
26272829303101
02030405060708
09101112131415
16171819202122
23242526272829
30010203040506
February 2018
MonTueWedThuFriSatSun
29303101020304
05060708091011
12131415161718
19202122232425
26272801020304
January 2018
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29303101020304
December 2017
MonTueWedThuFriSatSun
27282930010203
04050607080910
11121314151617
18192021222324
25262728293031
November 2017
MonTueWedThuFriSatSun
30310102030405
06070809101112
13141516171819
20212223242526
27282930010203
September 2017
MonTueWedThuFriSatSun
28293031010203
04050607080910
11121314151617
18192021222324
25262728293001
August 2017
MonTueWedThuFriSatSun
31010203040506
07080910111213
14151617181920
21222324252627
28293031010203
March 2017
MonTueWedThuFriSatSun
27280102030405
06070809101112
13141516171819
20212223242526
27282930310102
January 2017
MonTueWedThuFriSatSun
26272829303101
02030405060708
09101112131415
16171819202122
23242526272829
30310102030405
November 2016
MonTueWedThuFriSatSun
31010203040506
07080910111213
14151617181920
21222324252627
28293001020304
October 2016
MonTueWedThuFriSatSun
26272829300102
03040506070809
10111213141516
17181920212223
24252627282930
31010203040506
September 2016
MonTueWedThuFriSatSun
29303101020304
05060708091011
12131415161718
19202122232425
26272829300102
August 2016
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29303101020304
July 2016
MonTueWedThuFriSatSun
27282930010203
04050607080910
11121314151617
18192021222324
25262728293031
May 2016
MonTueWedThuFriSatSun
25262728293001
02030405060708
09101112131415
16171819202122
23242526272829
30310102030405
April 2016
MonTueWedThuFriSatSun
28293031010203
04050607080910
11121314151617
18192021222324
25262728293001
December 2014
MonTueWedThuFriSatSun
01020304050607
08091011121314
15161718192021
22232425262728
29303101020304
October 2014
MonTueWedThuFriSatSun
29300102030405
06070809101112
13141516171819
20212223242526
27282930310102