MiSTer FPGA Forum

Perhaps we can patch this, to add an extra 8k to each stack then grow downwards from there. So we never share code and stack.
http://aminet.net/package/util/boot/StackAttack2

So... this seems to be happen if the stack shares an mmu page with code. I refer here to the qemu mmu not the emulated 68k mmu.

When starting my tests from newcli this is the case and presumably other times.

Are there any amiga programs to force the stack location? They might be worth a try.

It seems to take this path rather a lot... All the time?

/* Handle anything that isn't just a straight memory access. */
if (unlikely(tlb_addr & ~TARGET_PAGE_MASK)) {

The performance issue is related to qemu write handling somehow. On every write it calls 'notdirty_write' (see access/tcg/cputlb.c) which does a glib tree lookup and a bunch of other messing around.. Which I can see if I set this trace event... trace-event memory_notdirty* on memory_notdirty_write_access 0x40025768 ram_addr 0x245768 size 4 memory_n...

So, still no performance fix...

However at least the irqs are better! Core/kernel module for the irq fix:
http://www.64kib.com/minimig_irq_corev2.tar.gz

(no qemu change needed, so still v9 - http://www.64kib.com/qemu_system_testv9.tar.xz)

So in theory qemu is executing these jit instructions... However when I debug it with gdb, I don't seem to get code at these addresses. In case there is an offset (it maps it as both read/execute and read/write at two addresses) I thought I'd do this a few times on all the executing threads: display/i $pc stepi Unfortunately I can't find the code i...

Is anyone here an arm assembly whiz?

http://www.64kib.com/qemu_slow_stuck_fragment.log

It logs IN: for the 68k code to translate, OUT: for the arm version then it logs which one its running. It also logs 68k addresses on entry.

So, found out a few more things... i) The irq implementation was still incorrect ii) The slow code is running completely locally in fast ram, no irqs and and hps-fpga bridge. The problem with the irqs as an off-by-one error and not understanding edge triggered irqs properly. I thought 'edge triggered' meant that on any edge I'd get an irq. So had j...

Not sure why, trying to register them in the rtl. Perhaps glitches?

I do see IRQ avalon bus accesses, which is unexpected. After Disable they should be off - and indeed I do not see the ipl lines changing in signaltap.

& I see no accesses to the hardware/chipram!

Checking the irq area too, just in case.

After some red herrings with icount etc... It seems to be a single chain of translation blocks. Which is what I'd expect. So I guess one of them accesses the hardware area, otherwise I really don't understand.

Time to signaltap...

It normally seems to say something like this:
(qemu) info profile
async time 814716981 (0.815)
qemu time 754223562 (0.754)

When I run the test app I see this:
(qemu) info profile
async time 34714891552 (34.715)
qemu time 0 (0.000)

I thought I should at least try building qemu with 'enable-profiler' to see if it tells me anything!

robinsonb5 wrote: ↑Sun May 16, 2021 5:47 pm What happens if you surround the test program with a Disable() / Enable() pair?

That didn't seem to change it.

Though, something interesting. I ran it several times and it went at full speed sometimes! (To be clear that was with the unchanged build where I didn't add Disable/Enable)

So I run this simple code: 00000000 <_start>: 0: 4e56 fffc linkw %fp,#-4 4: 42ae fffc clrl %fp@(-4) 8: 6004 bras e <_start+0xe> a: 52ae fffc addql #1,%fp@(-4) e: 0cae 00ff ffff cmpil #16777215,%fp@(-4) 14: fffc 16: 66f2 bnes a <_start+0xa> 18: 4e71 nop 1a: 4e71 nop 1c: 4e5e unlk %fp 1e: 4e75 rts In C: for (int i=0;i!=0xffffff;++i) { if ((i&0xff...

Here is the updated qemu that changes the irq handling, making it more stable:
http://www.64kib.com/qemu_system_testv9.tar.xz

As a reminder here is the kernel module that you need to setup on boot:
http://www.64kib.com/minimig_irq_core.tar.gz

Hopefully v10 will be stable and faster...

Although I know it’s not just executed code since I tested the same binary with musashi and qemu. Musashi won massively!

The compiler is different.

Latest m68k gcc for Debian and this one for Amiga:
https://github.com/AmigaPorts/m68k-amigaos-gcc
I’ll have a look at the code they produce.

Anyway I’m on to literally testing a for loop now running in fast ram - so that shouldn’t come into it!

I copied rom into fast ram, so that doesn't go over the bridge. But 0xe0 isn't rom is it? ... checks memory map, hmmm perhaps I should put that first 512k here too. int rom_bytes = 1*1024*1024; void * rom_addr_orig = mmap(NULL,rom_bytes,(PROT_READ|PROT_WRITE),MAP_SHARED,fdcached,hpsbridgeaddr+0xf00000); void * rom_addr_fast = malloc(rom_bytes); for...

Onto the next question... performance. In musashi this program takes 1 minute 50 seconds. In qemu 'mister' this program takes > 6 minutes (I gave up timing but I tested it finished before probably about 10 mins) From linux m68k qemu it takes <2 seconds. /media/fat# ./run_m68k ./dhrystone_m68k -l 1 duration: 0 seconds number of threads: 1 number of ...

Finally some progress on the icon double click crash issue. Seems to be due to something like this: i) IRQ processing starts ii) cpu writes to disable irqs, immediately after I poll the irq line iii) cpu writes to enable irqs, immediately after I poll the irq line iv) RTE Usually at step (ii) I read IPL2:0 of 15 -> i.e.no IRQ Sometimes at step (iii...

Definitely happens too if I boot the vanilla install 3.1.4 pdf (no hdd) then double click the icons.

This is the image I'm using. It is basically vanilla except: i) mister shared filesystem (mount share:) ii) Peter K's icon library from Aminet iii) 68040.library from the phase V Aminet link posted (68040old.library as 68040.library) http://www.64kib.com/HDDSmallTestOnly.hdf.gz Its just a 10MB image but compressed down to a couple of MB. I'm runnin...

ZigZag wrote: ↑Thu May 13, 2021 11:06 pm Maybe you could share VHD (make certain there's an "H" in that).

Its a bit big to share, so I'll cut it down first.

Its really just a vanilla 3.1.4 rom and 3.1.4.1 workbench install. The only changes were that I copied 68040old.library into libs:68040.library and now I installed this Peter K icon_68020.library into libs:icon.library.

Good thought, put that icon.library on. Unfortunately nope!

I make something and it works for everyone but me!

I tried the same drive image with 68040 on FS-UAE. It runs fine, no crashes. So does seem core related, or my DE10 related.

kolla wrote: ↑Thu May 13, 2021 9:36 am I have set up 3.1.4(.1) and using 68040.library from OS 3.1 (for some reason, 68040.library (44.2) from OS 3.9 doesn’t load) and I don’t have any issues with clicking or double clicking.

With qemu and the kernel module?

@kolla: I wonder if it works for you, perhaps its a timing bug that is fixed in 3.9. I've used 3.1 and 3.1.4.