New 0.9.13-WIP, with support for scopevanilla’s monitor type:

http://forum.fobby.net/index.php?t=msg&th=581&start=0&

It’s one of the run-time compiler code generation correctness tests. If it fails, it means the compiler generated bad executable code.

I implemented it after a compiler bug made me think I was going crazy when I was working on some new PC-FX code.

Does http://mednafen.sourceforge.net/wariohli.png look right(left/right view will depend on the positioning of your browser window I’d imagine)?

That 3D mode isn’t supported currently. Is it like line 0 goes to left eye, line 1 goes to right eye, line 2 goes to left eye, etc?

I could implement this 3D mode, though there may be performance issues.

Oops. I almost never use the watch area, so it’s rather buggy.

Hit the “M” key before shift+enter to work around the bug.

Graphics viewer as in tile viewer?

I’ve released 0.9.12-wip at http://forum.fobby.net/index.php?t=msg&goto=1789&#msg_1789

Not too much is new as far as VB goes, but more of the debugger functionality is working now.

I’m curious if the new Win32 build is slower or faster than 0.9.0-wip on older/slow computers.

It looks like you’re multiplying a constant(loading immediately before the mulf.s) floating point number by a denormal. The V810 will never(AFAIK) generate a denormal as the result of an FPU operation, as any result that would be a denormal is replaced with zero.

…and on another run, it looks like the result of the mulf.s instruction is larger that can be expressed in an integer, so cvt.sw is generating an exception.

Would it be an incorrect guess that you have no idea how your random number generator works, nor its mathematical properties?

Donation info was taken down to avoid possible future legal trouble as patent, copyright, and trademark law in a certain country whose name shall Not be Named is ****ing insane and getting worse.

Speaking of iterating, the V850 had a good idea with the SLD and SST instructions; load/store in 16-bit-long instructions(normal LD/ST instructions are 32-bit-long), with a fixed base register, and greatly reduced offset range, perfect for iteration!

I’m pretty sure ZDA means “zero data area” but I don’t understand why accessing stuff at lower addresses speeds up or shrinks the code… Why couldn’t you just put an address in, e.g. R15 and then use “offset[R15]” to achieve the same effect?

The loading of the address into a register takes CPU cycles too, you know. 😉
It probably won’t help much when you iterate over arrays, or use a lot of structures. It really helps when you have some global/static variables all over the place that you want to access quickly.

I also understood: “the first 32KiB of the V810’s address space”. I know you’re more interested in the PC-FX, but I don’t think that would work on the VB, since that area is used by the VIP (specifically, one of the left frame buffers and the first 512 characters). The “work” RAM area is the 64K at 0x0500XXXX.

Bizarre.

I.e. does that patch turn the V850 support into V810? Or does it not even care if the V850 support is there? If it adds it from scratch, the architecture may have changed enough that the whole patch will have to be made again…

AFAIK, the patch only adds files and modifies build scripts/makefiles, it doesn’t touch the V850 support at all.

RunnerPack wrote:
Well, since I hadn’t even heard of the flag “-mzda=n” before this post, I never actually experienced this bug.

-mzda=n forces all global and static data variables/structures <= n bytes in size to be located in the first 32KiB of the V810's address space, so that "offset[r0]" type of addressing can be used, for smaller and faster code in many cases. Also, for some reason, the linker scripts appear to start the ZDA at 0x160 instead of 0x0. Maybe to conform to NEC's (un?)published V810 ABI? (Random rants: the V810 doesn't really suck, but it really needs clever usage of its I/O and memory maps for optimal code, that the PC-FX lacks in several cases...and I wonder if NEC's proprietary V810 compilers take into account DRAM page change penalties...)

I wonder if it (and/or the previous one) are bugs in gcc or in the v810 patch. I suppose someone(s) should be trying to get a more mature version of gcc to output v810 code… It still irks me that someone felt the need to actually remove that target from the compiler >:( I thought OSS was about gaining features, not losing them!

-mzda=n is an architecture-specific option, so it’s not a problem in the core of gcc. I don’t believe V810 support was ever included in mainline gcc, it has, AFAIK, simply existed as a patch(and some pre-patched unofficial tarballs, of course). V850 has and still is in gcc, though. I’ve made a list of major differences in the instruction sets between the two…

I found another bug in the assembler, that will break(seg fault in gas called by gcc during compilation) the gcc optimization control argument “-mzda=n”. In binutils-2.10/gas/config/tc-v810.c:

            case AREA_SDA:
              if (sbss_section == NULL)
                {
                  sbss_section = subseg_new (".sbss", 0);

                  bfd_set_section_flags (stdoutput, sbss_section, applicable);

                  seg_info (sbss_section)->bss = 1;
                }
              break;

            case AREA_ZDA:
              if (zbss_section == NULL)
                {
                  zbss_section = subseg_new (".zbss", 0);

                  bfd_set_section_flags (stdoutput, sbss_section, applicable);

                  seg_info (zbss_section)->bss = 1;
                }
              break;

bfd_set_section_flags() is called with the wrong section variable in case AREA_ZDA. Changing it to be zbss_section instead of sbss_section appears to fix the problem. Has anyone else encountered this bug?

A mischievous mysterious mad (h/cr)acker working on a gcc, stripped-down newlib, and ‘custom library whose name I have not decided upon’-based toolchain for PC-FX development.

Two(that I know of) toolchains already exist, one being the official NEC one, and the other being a modification to enable NEC’s libraries and header files to work with gcc. NEC’s libraries have unclear license terms, and horrid misspellings.

Aaaaand…cats go meow!