Aviron features #683

Grazfather · 2025-09-24T08:42:24Z

Add a feature to detect infinite loop halts.
Initialize SP properly to RAMEND - 1 (though gcc-compiled binaries will set this for us)
Add a Mapper to the CPU struct. All reads and writes go through it. It will properly delegate to SRAM or IO.
Map SRAM to 0x100 at atmega328p. Needed for when low registers are modified via writes rather than in
Detect when killed via IO, and return normally.
Dump full state when the program halts, when trace is set.
- Dump ram, with ASCII representation
- Elide repeated lines of all zeroes

sim/aviron/src/lib/Cpu.zig

Grazfather · 2025-09-27T12:03:33Z

sim/aviron/src/main.zig


                    const addr_masked: u24 = @intCast(phdr.p_paddr & 0x007F_FFFF);
+                    const target_addr: u24 = if (phdr.p_paddr >= 0x0080_0000)
+                        addr_masked - sram.base


❯ avr-readelf -s test.elf Symbol table '.symtab' contains 396 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00800100 0 SECTION LOCAL DEFAULT 1 .data

.data is at 0x00800100, but it should start at 0 in the array, so we mask off the top 8, then adjust by the base (0x100)

The logic here is flawed as two LOAD headers at 00800100 and 00800200 would both be offset, while the third LOAD header at 00800000 would not.

You have to basically go through cpu.data_write for this instead of hijacking the data in a conditional here.

With a proper mapped SRAM object instead of a single "Static" this would not be a problem.

I think we should introduce a real mapper object here already, as we're piling up workarounds on workarounds just to not have a mapper and introduce more complexity than necessary by that.

The branch would not be necessary if we could just do ram.write(addr_masked, data)

I've written a mapper, but it only supports writing individual bytes. I could extend it to add a method to write a slice, but with the changes to this part (take a look at new commits) I think this is probably fine.

In your example case, though: How would there be a load at 0x00800000 if SRAM starts at 0x100?

Grazfather · 2025-09-27T12:04:13Z

sim/aviron/src/main.zig

        .m = "mcu",
        .I = "info",
        .f = "format",
+        .B = "break_pc",


could be lower case?

Grazfather · 2025-09-27T12:04:25Z

sim/aviron/src/main.zig

            .mcu = "Selects the emulated MCU.",
            .info = "Prints information about the given MCUs memory.",
            .format = "Specify file format.",
+            .break_pc = "Break when PC reaches this address (hex or dec)",


You wanted to call this 'breakpoint'?

I'd go with either aviron --break-at 0x1000 or aviron --breakpoint 0x1000

Grazfather · 2025-09-27T12:05:12Z

sim/aviron/src/main.zig

            .sreg => write_masked(@ptrCast(io.sreg), mask, value),

-            _ => std.debug.panic("illegal i/o write to undefined register 0x{X:0>2} with value=0x{X:0>2}, mask=0x{X:0>2}", .{ addr, value, mask }),
+            _ => {


should probably restore the panic.

We should definitly crash/stop here in any case, and not silently ignoring it

ikskuh

I guess the main pain point is that we should introduce a proper memory mapper instead of doing all of these workarounds, as it will actually simplify the code a lot

sim/aviron/src/lib/Cpu.zig

ikskuh · 2025-10-02T07:34:55Z

sim/aviron/linker.ld

        KEEP(*(.vectors))

+        /* Ensure _start comes first */
+        KEEP(*(.text._start))


This won't always hold true as .text._start will only be present with -ffunction-sections compile flag (which is on in default for Zig code, but not for C and definitly not for Asm)

is _start not exported normally for gcc? If not, what can we add here as an alternative?

ikskuh · 2025-10-02T07:37:16Z

sim/aviron/src/lib/io.zig

+    // Some AVR families (e.g., XMEGA) expose extended I/O up to 0xFFF (12 bits).
+    pub const Address = u12;


Which instructions would use these? Afaik the 1024 byte I/O is only usable via the RAM interface?

It's not for io instructions, it's for MCUs with IO mapped and read/writable with normal load and stores.

ikskuh · 2025-10-02T07:38:09Z

sim/aviron/src/lib/io.zig

+        checkExitFn: *const fn (ctx: ?*anyopaque) ?u8,
+        translateAddressFn: *const fn (ctx: ?*anyopaque, data_addr: u24) ?Address,


We could add default implementations for these two, where both functions will return null by default

Added a empty() function to return an IO with dummy functions. Would you prefer that the vtable have default values so an empty version can be initialized with.{} instead? I find this more expressive but I don't mind either way.

ikskuh · 2025-10-02T07:43:02Z

sim/aviron/src/main.zig


                    const addr_masked: u24 = @intCast(phdr.p_paddr & 0x007F_FFFF);
+                    const target_addr: u24 = if (phdr.p_paddr >= 0x0080_0000)
+                        addr_masked - sram.base


The logic here is flawed as two LOAD headers at 00800100 and 00800200 would both be offset, while the third LOAD header at 00800000 would not.

You have to basically go through cpu.data_write for this instead of hijacking the data in a conditional here.

With a proper mapped SRAM object instead of a single "Static" this would not be a problem.

I think we should introduce a real mapper object here already, as we're piling up workarounds on workarounds just to not have a mapper and introduce more complexity than necessary by that.

The branch would not be necessary if we could just do ram.write(addr_masked, data)

ikskuh · 2025-10-02T07:44:07Z

sim/aviron/src/main.zig

            .mcu = "Selects the emulated MCU.",
            .info = "Prints information about the given MCUs memory.",
            .format = "Specify file format.",
+            .break_pc = "Break when PC reaches this address (hex or dec)",


I'd go with either aviron --break-at 0x1000 or aviron --breakpoint 0x1000

ikskuh · 2025-10-02T07:44:51Z

sim/aviron/src/main.zig

            .sreg => write_masked(@ptrCast(io.sreg), mask, value),

-            _ => std.debug.panic("illegal i/o write to undefined register 0x{X:0>2} with value=0x{X:0>2}, mask=0x{X:0>2}", .{ addr, value, mask }),
+            _ => {


We should definitly crash/stop here in any case, and not silently ignoring it

…ocess

Grazfather requested a review from ikskuh September 24, 2025 08:42

Grazfather commented Sep 24, 2025

View reviewed changes

sim/aviron/src/lib/Cpu.zig Outdated Show resolved Hide resolved

Grazfather commented Sep 24, 2025

View reviewed changes

sim/aviron/src/lib/Cpu.zig Outdated Show resolved Hide resolved

Grazfather commented Sep 24, 2025

View reviewed changes

sim/aviron/src/lib/Cpu.zig Outdated Show resolved Hide resolved

Grazfather marked this pull request as ready for review September 26, 2025 12:53

Grazfather marked this pull request as draft September 26, 2025 16:03

Grazfather added the aviron label Sep 26, 2025

Grazfather force-pushed the aviron_fixes branch from 88e66b0 to 1632125 Compare September 27, 2025 11:50

Grazfather force-pushed the aviron_features branch from 5ed6544 to 41ae681 Compare September 27, 2025 11:50

Grazfather changed the base branch from aviron_fixes to main September 27, 2025 11:53

Grazfather marked this pull request as ready for review September 27, 2025 12:16

Grazfather commented Sep 27, 2025

View reviewed changes

ikskuh requested changes Oct 2, 2025

View reviewed changes

Grazfather added 17 commits October 2, 2025 18:18

Aviron: Cleanup tests, rebuild binaries

f0a19ee

aviron: Detect infinite loop used as halt

3aa9ab1

aviron: Fix SRAM mapping

cd4b8db

aviron: Add comments to clarify push/pop semantics

c6aa678

Add support for breakpoints and mileage

a3099f8

Add some debugging

19d55df

tests: Make the expected value output hex

88b6706

revert debug stdout

461a8f0

aviron: cross-platform copy testsuite

7895119

Add check_exit method to IO to capture exit instead of killing the pr…

df44122

…ocess

fixme: Fix circular dependency in test

28ce9fe

update readme

475b124

Dump end trace only if trace is set

79b2dae

Update build.zig just to clean it up

3c53582

fix circular dep in test builds

225b99b

fix zig-build AVR test binaries

cd1a23e

Cleanup state dumping

302ea81

Grazfather added 10 commits October 2, 2025 18:18

cleanup debug

2851523

dump

ffb9b51

cleanup comments

20e5c11

update tests final

f07dfb8

wip base

62f6cb3

wip: Mapper

5ccf128

address type and rename get_base and print range

b1f5d01

elide repeated lines in hex dump

2583411

Add ascii rep in mem dump

6f8519e

Only elide sram dump of all zeroes

65393d1

Grazfather force-pushed the aviron_features branch from 41ae681 to 65393d1 Compare October 2, 2025 22:18

Grazfather added 5 commits October 2, 2025 19:56

aviron: Add simple mapper

0d101a7

Remove base field from Flash

d464a97

Multi mcu support

4bb14b1

Rename break_pc to breakpoint

873e3ce

Restore panic on write to unimplemented IO

fd54e9b

Grazfather force-pushed the aviron_features branch from 5240640 to fd54e9b Compare October 3, 2025 00:09

		// Some AVR families (e.g., XMEGA) expose extended I/O up to 0xFFF (12 bits).
		pub const Address = u12;

		checkExitFn: const fn (ctx: ?anyopaque) ?u8,
		translateAddressFn: const fn (ctx: ?anyopaque, data_addr: u24) ?Address,

Aviron features #683

Are you sure you want to change the base?

Aviron features #683

Conversation

Grazfather commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ikskuh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Grazfather commented Sep 24, 2025 •

edited

Loading