Sun Mon Tue Wed Thu Fri Sat
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
|
Exhibitions
In the afternoon, I went into the city. At Concordia, I saw some
exhibitions. I went there to see the exibition
Triangle in Square by Wineke
Gartz. She creates site-specific installations. I found it quite
interesting how she transformed the second floor of the building using some
projectors and clothes hanging from the ceiling together with some other
attributes. Downstairs, I discovered that I only saw part of the exhibition
Kunstblikken when I went to see it on July 17. At that time, I only
visited the room in the front and did not realize that the exhibition on the
rest of the floor. On the ground floor there were also some 'tree houses'
constructed by Tessa Hendriks with the help of Yonatan, Nakom, Humd and Fnot.
Preventing care fraud
Today, the Dutch investigative journalism organization 'Follow the Money'
reported (Article in Dutch) that in the Netherlands the fraud with healthcare money
is about 10 billion per year. The article reports that the main perpetrators
use front men to stay out of the picture themselves. The front men go to the
Chamber of Commerce and start a new healthcare company without any problem,
which then starts to invoice. I presume that these invoices contain fake data
for care that never has been delivered. I do think, using digital certificates,
and maybe some app, it is possible to prevent these fake invoices. I think it
is possible to create an app for a smart phone with GPS and NFC to verify that
at a certain time an ID-card has been scanned at a certain location. The Dutch
company Inverdi has developed the
ReadID ME app with which it
is possible to verify a chipped identity document. The company TrueScreen has developed technology to certify a GPS location with time, I presume. I am really surpised that
this kind of technology has not already been implemented and/or enforced by out
government. I think that one of the biggest problems is that the national
government itself does not have ICT specialist who could support the government
with implementing these kind of anti-fraud measurements. In the past decades a
lot of essential ICT knowledge has been outsourced to companies under the guise
of privatization. I think it is okay of companies are used to implement and
service ICT systems. But the specification and risk assement should be done by
independent specialist working for the government. For example, recently it was
discovered that more and more government organization were outsourcing ICT to
cloud based solution owned by foreign countries, not realizing that cloud
services by US companies, no matter where they are located, still fall under US
laws, and give the US government full access to the stored data in case it
wants to. It seemed that those Dutch government organization were not aware of
the implications of this and that they might even violated national and
European laws with respect to privacy and security legalislation.
In the past days, I have been working on improving the program for the cubes from a sheet problem that is based on using tiles. The program was
generating lots of encodings between columns that never occured in some
sequence from wall to wall. The idea is to find a simple way to rule out
those encodings. Each encoding between two columns of tiles consist of
encodings for connecting two tiles at each height. The idea is to look at the
two of those encoding directly above each other and see if there is a
continuation for them. For that I took some code from the bricks.cpp program I posted on July 7. This resulted in the program CubesFromSheet3.cpp This did result in some improvement, however
it did not get me much further. Calculating all results for a height of seven
tiles, took some considerable time. In the table below for each height it
gives: the number of different encodings between the columns, the number of
different columns that are possible and the number of encodings that actually
occure in some sequence from wall to wall.
2 11 17 11
3 66 158 53
4 473 1561 357
5 3194 14704 2193
6 21603 138949 13889
7 145910 1311680 87361
Arabic Typography: History and Practice
I finished reading the book Arabic Typography: History and Practice with Titus Nemeth as editor
and author, which I started reading on April 26 after I received it on April 4.
I already wrote something about reading this book on May 6. I did enjoy reading the book. It is a bit more about typography than about Arabic typeface design, as I had hoped. I do like the typography of the book with
it use of yellow. I think that at the start of the book in an introduction,
there should have been some pointer to advice people who are not yet familiar
with Arabic script to first read the last chapter of the book titled:
Foundations of Arabic typography. I did know that Arabic letters have
different forms depending whether they appear at the start, the end, or in the
middle of a word or when they appear isolated. But I did not know that the
character bā' (ب) when followed by other letters, may assume up to
24 different initial forms as shown in figure 5 op page 322. This shows some of
the complexities of the Arabic script. I also understand from this chapter that
the software support for Arabic typography is still rather limited. One of the
reasons is that text justification for Arabic text uses different techniques that even
depend on the type that is being used. A lot is probably related to the fact
that Arabic has a much richer history with respect to calligraphy than the Latin script. I also get the impression that the
Arabic script has been used for very different languages with local traditions.
Some of the chapters of the book are rather academic in the sense that they are
the product of academic research into historic developments. Definitely
interesting to read.
A stack-oriented language
Since the last time, I reported about
M2-Mesoplanet, I did find the bug that I was struggling with, but soon, I
encountered another bug. Then I spend some time working on the cubes from sheet problem. In the past days, I spend some time
looking at the first stage, stage0-posix, of live-bootstrap with respect to the four supported CPU. I did write a
shell script, run_chroot_AMD64, to execute the AMD64 variant and analysed the
the strace output. Yesterday, I spend some time reading the code of
cc_x86.M1 and taking notes. I also started thinking about a
minimal language that can be easily compiled to the M1 format. I was
thinking about a stack-oriented language. I had to think about the thesis
Lawine, an experiment in language en machine design by
Sjoerd Doaitse Swierstra in which a machine design with multiple stacks is
described. I was thinking about a design with three stacks: The normal stack
used for function calls, a stack for values that are being processed and/or
passed to function calls, and a stack with values of local variables defined in
the functions. In the machine code generated when compiling C these stacks are
intermixed, which requires some additional administration and taking care that
they are not mixed up. This approach is actually one of the reasons for
allowing execution through buffer overflows. This stack-oriented language will
be a similar to Forth but with local variables making programming easier. I am not sure
yet, whether it will also incorporate structured control statements for choice
and loops. I think, I will first try to write C++ program to compile the input
to a file in the M1 format, and if that works out, see if I can
implement it in the language itself.
Two stack implementation
I have been thinking about a two stack implementation of the stack language I
was talking about last Friday. The idea is to use the 'normal'
stack for stack oriented operations and have another stack for storing local
variables and the return address. On the i386 the normal stack is stored in the esp register and has
dedicated instruction, push and pop, to work with this stack.
To prevent a lot of push followed by a pop the eax
register will be used to store the top element of the stack. Furthermore, the
idea is to store the local variables on another stack and use the ebp
(Base Pointer) stack for this. It is important to note that the call
instruction pushes the contents of the eip (Instruction Pointer) on
the stack and that the ret (return) instruction jumps to the address
stored on the stack. As this interfers with the idea that the stack only
contains values to operate on, the address could be stored on the second stack.
Before calling a function, the ebp register has to be incremented with
the current number of bytes that have been used for local variables and the
return address and afterwards it needs to be decremented with the same value.
The code for calling a function (using the GNU Assembler syntax), where the start address is stored in the
eax register and n stands for the size used for the
second stack, then becomes:
add ebp, n
call [aex]
sub ebp, n
Now, at the start of the function being called, the return address is stored
at the first location of the second stack, using the instructions:
pop eax
mov [ebp], eax
pop eax
Where the second pop instruction is used to pop the address of the
function that was called. The instructione to exit a function and continue the
execution of the previous function now becomes:
mov ebx, [ebp]
push ebx
ret
This might look rather a lot of instructions, but actually it is not so much
more than tradition method for implementing function calls.
Kraftwerk: Future Music from Germany
I finished reading the book Kraftwerk: Future
Music from Germany by Uwe Schütte that I started reading on June 28 while traveling in the train. I bought the book earlier this
year on January 19. The book is about the German
electronic music band Kraftwerk. I had somehow hoped that the book would tell something about
the equipment that they had used, but there was little information about it. It
was primarily about the cultural context in which the band operated and the
impact it had. I only knew about Kraftwerk for some of the hits they had in
the seventies and the eighties. It was interesting to read what happened with
the band in the following years and also understand something about the
cultural context of the band.
The temperature at Twenthe Airport has gone up to
33.6° Celsius, which breaks the previous record of 32.7° on this date
in 1953. Today, the humidity was rather high. It is long ago that I have felt
such a combination of high temperature and high humidity. For dinner, we had
curly kail hotchpotch with spice mixture,
gherkins and sausage, which is a typical winter dish, but we had gotten some
more curly kail in the harvest last Saturday. At the start of the evening,
there were was thunder storms around us, causing the temperature between 19:20
and 20:00 to drop about ten degrees. We did just a little rain. At 20:25, we
saw a small, but rather bright segment of a rainbow. Below a picture, I took of this small fragment
Yellow from Bloemendaal
In the harvest from Herenboeren Usseler Es we
were given two large paksoi and also two heads (large and small) of
"Bloemendaalse Gele" (which translates to "Yellow from Bloemendaal"), an old variety that is somewhere between pointed cabbage
and savoy cabbage. It is quite possible that some of my ancestors, who were
vegetable growers, also grew it and possibly even cultivated it. In addition
(depending on personal choices where possible) I came home with: a spaghetti
squash, seven red onions, two leeks, two gherkins, one cucumber, three
courgettes, a fennel, a broccoli and two heads of lettuce (with red edge).
From the things we were allowed to harvest ourself from the beds, I took some
basil and some rocket. We were also asked to help harvest potatoes, but that
did not happen. The ground was too wet. I heard someone say that 2 cm of rain
fell last night. That could well be because I heard it rain last night.
This afternoon, I visited the exhibition
'Meesterwerken' at Fotogalerie Objektief with photographs from ten students
from the photographers course at the secondary vocational education instituion
'ROC van Twente'. I liked the photographs by the following students:
'hello world!'
I have been working on a compiler for a small stack based language for the
purpose of writing a compiler to replace the MES-compiler of live-bootstrap. This compiler is based on the suggested solution I
proposed a week ago. This evening, I succeeded in
compiling the program below that prints the text 'hello world!'. The
language uses a Reverse Polish Notation for expressions. It allows the definition of
functions (with the keyword func), has loops (with the keyword
loop and ways to escape it with the keyword break and repeat
it at any point with the keyword continue), a choice statement (with
the keywords then and else), and definition of local
variables (with the keyword var). The program below defines the
function fhputs to print a string. The function makes uses of the
build-in function sys_fputc that prints a single character to a give
destination specified with an integer. In this case the integer '1' is
used to reference the standard output. A function is called with '()'.
The value that the function sys_fputc returns needs to be deposed with
using pop. The program contains the function main, which is
the main function that is called when executing the program. It simply call the
function fhputs
func fhputs
{
var s s =
loop
{
s ? ?1 0 == then { break }
s ? ?1 1 sys_fputc () pop
s ? 1 + s =
}
ret
}
func main
{
"hello world!" fhputs ()
ret
}
The compiler is a single pass compiler with minimal storage. It keeps a stack
oriented symbol table and a stack for the statement nesting. There is an almost
one to one translation to 'machine code' in the format that is excepted by the
M1 compiler of stage0-posix that is part of live-bootstrap. The language and the compiler are rather primitive and do
not prevent many kinds of errors. The first version of the compiler, which is
very much work-in-progress and contains some known bugs, can be found in the
commit 590e5315. This commit contains the batch-file
build_stack_hello that contains all the calls to compile the
hello.sl program and to run it. A number of intermediate files are
produced including the file hellosl.txt that is produced by calling
objdump.
I am still thinking about how to continue from this point. One thing would be
to write the compiler in the language itself. I think this is possible, but I
think I first want to develop the C++ version further, before I start doing
this.
Programming language design
In the past week, I continued working on the stack based language as part of
the attempt to replace the MES-compiler of live-bootstrap. I have worked on translating the C preprocessor (written
in C++) to a program in the stack language. I made some improvements to the
stack language to make the programs look more similar to the program in C++.
I discovered that bugs are easily introduced when doing the manual translation
and that debugging those bugs is not easy. I use objdump to disassemble the code, compare this with the file
produced by the compiler for the stack-based language to match this to the
program. I have thought about a program to optimize this process, but so far
did not do any work on that. I did think about the language design. For
example, in most language when a variable is used in an expression, it is
interpretted as taking the contents of that variable and not the memory address
of where the variable is located in memory. The C programming language has an
operator, a single ampersant ('&'), to indicate that the address of a
variable should be used. In the stack language, it is the opposite, you have to
explicitly use an operator, the question mark, to retrieve the contents of the
variable, instead of using the address. Note that in a language like C when a
variable is mentioned as a target for an assignment (on the right-hand side)
the address of that variable is to be used as the target for the assignment,
not its contents. So, if in the stack language, I would want to avoid the
very frequent use of the retrieve operator, the compiler would have to perform
some analyses about what comes next. And I would like to keep the compiler as
simple as possible. This having to make every operation explicit also makes
you even more realize what is going on under the hood. Another thing that I
have been thinking about is the constants that are defined for accessing
fields/members of a record ('struct' in C). These constants are specific for
a certain struct type, but because the constants are global, this means that
a prefix is needed in case several records have the same field names, which
could be placed at a different offset from the start of the record. The stack
language now has, because it is rather simple, certain limits that make it
impossible to define 'local' constants for this. I did think about some ways
to improve on this, without making the implementation a lot more complex. I
have not made any changes with respect to this. While tranalating the C++
program to the stack language, I realized that I could try to automate it and
realized that the stack language would be a good target language. This made
me decide to switch to developing the preprocessor again.
Drents Museum
Conny and I went to Drents Museum. We first visited the exhibitions Dacia - Empire of gold and silver, which shows more
than fifthy gold and silver treasures and many more small rings and coins from
Dacia from the
stone age (3rd century AD) till about the roman conquest in 106 AD. After this
we visited the exhibition: Figures of speech with the following
sculptures:
- Hare, Carolien Smit, 1999.
- Drenthe heath sheep, Carolien Smit, 2017.
- Untitled, Juul Kraijer, 2008.
- Self-portrait, Gert Sennema, 2022.
- Selbst, Laura Eckert, 2021.
- Mary, Laura Eckert, 2021.
- Self-portrait, Stephan Balkenhol, 2022.
Next we saw the exhibition Christine and Janus van Zeegen: Innovators in thread
and paint. I found the following works noteworhty:
- The Bride of Van Zeegen, Janus van Zeegen, 1925.
- Light poetry. Image of Christine van Zeegen, Janus van Zeegen, 1928.
- The child Christine van Zeegen, 12 years old, Janus van Zeegen, 1902.
- Phoenix bird, Christine van Zeegen, 1918.
- Rooster, Christine van Zeegen, undated.
- Study of an owl, Janus van Zeegen, 1920.
- Fantastically-styled Bird Flight, Janus van Zeegen, circa 1920.
- Deep-sea garden or Coral inhabitants on the seabed, Janus van Zeegen, circa 1918.
- Solitude, Alexander Drenth, 2024.
- Requiem, Alexander Drenth, 2024.
- Silent Eternity, Christine van Zeegen, 1915.
- Christ;s ascension, Christine van Zeegen, 1915.
- Church owl, Christine van Zeegen, 1917.
- One valved pearl oyster shell, Janus van Zeegen, 1936.
- The eruption, Janus van Zeegen, undated.
In the enterance hall, where there is also bookshop, there was a memorial of
Matthijs
Röling who died on July 10 with four of his works:
Nedko Solakov: Leftovers
Since last Tuesday, I have been reading in the
exhibition catalogue Nedko Solakov: LEFTOVERS that I bought May 1, which is about a collection of unsold pieces from the private
galleries Nedko Solakov work with. I
initially bought the book because it has lots of numbers and letters on the
cover. Now I understand that these are just consecutive ranges of numbers
with some letter attachted, where the letters refer to earlier exhibitions
from which the works were leftover, e.g., not sold. I read most of the
introductions to the various exhibitions. Some pages contain reproductions of
pencil written remarks by Solakov. This is a bit similar to how at one
exhibition at Módulo
Centro Difusor de Arte he made drawings and writings on the walls of the
exhibition rooms got more attention that the works at display. Several
collectors bought piece of plaster with those drawings and writings.
Tiny chestnut
This afternoon, while walking around the neighbourhood, Conny gave me a tiny chestnut she had found
on the road.
I²C is a serial
communication bus that is often used for allowing microcontrollers to communicated one or more peripherals. The bus makes
use of two active wires and a ground wire. One active wire is used for data
communication and the other for a clock signal. Usually the microcontroller
acts as a master, generating the clock signal, and the peripherals acts as
slaves. BadgerOS is an
operating system
being developed by Badge.Team for the various
badge that are developed for various hacker camps and conferences, such as
WHY2025 that will be held next year
August. I have recently joined the Badge.Team and am going to look into the
support for I²C in BadgerOS.
The Hackerhotel 2024 badge uses I²C in the communication between the ESP32-C6
microcontroller and the CH32V003 peripheral that is used to read out the five
switches and control the LEDs. The code for the firmware can be found in
the Hackerhotel 2024 CH32V003 firmware repository. I have studied the code in
this repository. Some details about the protocol that is being used for the
communication (over the I²C bus) for communication with the
microcontroller is found in the function I2C1_EV_IRQHandler in the i2c_slave.h file. The firmware
for the microcontroller, an ESP32-C6, of the Hackerhotel 2024 badge can be found in the
repository hackerhotel-2024-firmware-esp32c6 repository. In the function
coprocessor_intr_task a call of the function
i2c_read_req is used to retrieve the states of the five buttons. The
first arguments specifies the number of the bus (needed in case the
microcontroller has multiple I²C communication busses). The second
argument specifies the unique identification of the slave peripheral, which is
hexadecimal 42, refering to The Answer to the Ultimate Question of Life, the Universe, and Everything is
42. The third argument is the register number that should be read. The
fourth argument is a pointer to the byte array where the data should be stored
and the last arguments is the size of that are and the number of registers that
should be read. The function is defined in the file managed_i2c.c, which contains some more i2c_read and
i2c_write functions. Only one of the write functions, the function
i2c_write_reg is called in the code. One such place is the in the
function bsp_set_leds in the file bsp.c. The functions in the
file managed_i2c.c are implemented with Espressif library for I²C.
This months interesting links
Home
| July 2024
| September 2024
