happz / ducky-legacy Goto Github PK

Extra section in docs, virt ints, their API, ...

When running testsuite, the only input channel FORTH has is the keyboard stream, and this is used for testsuite itself. There's no other way ACCEPT could use to read user's input. Possible solution would be teaching encoding the testsuite as a blob, and kernel would read it directly from memory then, leaving keyboard for ACCEPT.

Allow binaries in privileged mode to modify some memory settings - access attributes of pages/areas/sections, allocation/deallocation of memory pages (heap support), and maybe few others.

Main motivation is to support self-modifying code. One particular use case is my FORTH kernel, in which I'd like to compute checksums of words' names during the boot phase but these words are stored in .text and .rodata sections that are by default read-only, for a good reason.

As an option, this may be useful for debugging - revealing attempts to write read-only sections, while production would get PTE-free kernel.

Mostly to provide way to keep all caches (per-core instruction and data caches) coherent, when memory is accessed by many different actors - cores, blockio, and other devices with DMA capability.

.byte 0xFFFF, .short 0xFFFFFFFF. What's gonna happen? Probably EncodingLargeValueError should happen...

This would be more similar to real hardware, and I could optimize VM a bit, since it looks like most of the access is word-wide.

Right now each byte of each section is copied into memory. Using internal mmap feature would be much more efficient, especially for larger binaries and in case of more CPUs/cores.

One issue might arise in case of short binaries - internal mmap needs everything to be PAGE_SIZE-aligned, small binaries have sections of dozens of bytes - all sections, including RO data and data - would be mmap'ed into text section... Will it cause any issues? I don't know yet...

He who opens the stream should also close it. Make sure this is honored.

Currently all files are open for blocking IO, this - in case of large blocks or files stored on network filesystems - may lead to large time periods spent waiting for IO to finish, and starving other runnable resources (e.g other cores).

Provide another kind of device - network card. The easiest way is would be to create new virtual interrupt to access to a full network stack, emulated by machine with standard sockets.

#> [INFO] Loading IRQ routines from file interrupts.bin
[INFO] Section    Address      Size  Flags                                 First page    Last page
[INFO] ---------  ---------  ------  ----------------------------------  ------------  -----------
[INFO] .data      0x010000        2  <SectionFlags: r=1, w=1, x=0, b=0>           256          256
[INFO] .text      0x010100       64  <SectionFlags: r=1, w=1, x=1, b=0>           257          257
[INFO] stack      0x010200      256  <SectionFlags: r=1, w=1, x=0, b=0>           258          258
[INFO] 
[INFO] Loading binary from file examples/hello-world.bin
[INFO] Section    Address      Size  Flags                                 First page    Last page
[INFO] ---------  ---------  ------  ----------------------------------  ------------  -----------
[INFO] .data      0x020000       14  <SectionFlags: r=1, w=1, x=0, b=0>           512          512
[INFO] .text      0x020100       96  <SectionFlags: r=1, w=1, x=1, b=0>           513          513
[INFO] stack      0x020200      256  <SectionFlags: r=1, w=1, x=0, b=0>           514          514
[INFO] 
[INFO] #0: Booting...
[INFO] #0:#0:  Booted
[INFO] #0: Booted
[INFO] Guest terminal available at /dev/pts/10
Hello, world!
[INFO] #0:#0:  Halted
[ERRR] conio.__read_char: error=[Errno 5] Input/output error
[INFO] VM snapshot save in ducky-snapshot.bin
[INFO] Exit codes
[INFO] Core      Exit code
[INFO] ------  -----------
[INFO] #0:#0             0
[INFO] 
[INFO] Instruction caches
[INFO] Core      Reads    Inserts    Hits    Misses    Prunes
[INFO] ------  -------  ---------  ------  --------  --------
[INFO] #0:#0       117         26      91        26         0
[INFO] 
[INFO] Data caches
[INFO] Core      Reads    Inserts    Hits    Misses    Prunes
[INFO] ------  -------  ---------  ------  --------  --------
[INFO] #0:#0       161        193     161         0         0
[INFO] 

Some race condition maybe? Machine console has its own thread for checking input, there is potential for races.

Currently, only sync transfer mode is supported (via virtual interrupt).

Only strings are stored now. Extend binary sections to support storage of symbols like functions, to support relocation and debugging.

Ignored right now. Will require proper flagging of sections in binary file, and additional parameter of read_u32, to inform memory controller that read value will be executed as instruction.

It may be necessary to specify order of few sections in the final file. Add an option - similar to --section-base for this.

Currently both "foo" and "&foo" are supported, I think leaving ampersand to the history would have nice effect on code complexity - it's one more corner case I have to take care of...

JIT code does not keep track of stack frames, check-frames is purely debugging option. It would deserve some kind of warning when these two collide.

Something similar to C library, accessible via interrupts. Provide common functions like "write string", "read string", "copy memory", etc.

Implemented in C, compiled by ducky's compiler and loaded into memory...

Implement $SUBJ that would support:

• fine-grained setting numbers of CPU and cores
• allow defining which binaries (and routines) are bound to which core
• mmaping of external files into memory - this would mean routines can save and load their state - in fact it's persistent storage, masked as memory...
• configuration of IRQ, interrupts and their handlers and binding to CPUs/cores
• connecting input/output files (or terminals) as IO ports

All cores are asked to suspend but when core is already suspended - e.g. because of triggered breakpoint - it can't even pick up this message, and whoa - deadlock. All live cores - with running thread - are considered recipients, this should change to ignore already suspended ones.

Since I switched to using scons instead of make, Python 3 docker image cannot be built anymore. I overcame scons' limitations in CI runs, I believe I will work around its "Python 3 not supported" opinion in docker too.

... preferably these:

.comm
.data
.section
.text

Especially having more sections, defined by .section, would be beneficial - it would be possible to have more than one data data sections with different RW flags.