GNU/Linux compatibility

[HatCat]

The second option sounds simple enough. If matters on the branch weighing are handled appropriately, checking if the address is invalid should be a very miniscule cut by assuming that the validity of the address is by far the most likely branch case. However the Microsoft compiler seems to override that concept at times.

I have no idea what SEH is.

The third option would be the sexiest. Function-oriented templating is always a bit more 1:1 translatable to the human concept, but I would always avoid laying a series out except for cases where the conditional operations were too large or too complex to maintain in the local scope.

Also, I think that writing any code for portability, is a plus anywhere, not just GNU/Linux.
Linux would be a prime example for targeting portability, but keeping code simplicity and purity as a general rule of thumb should suffice over the need of targeting any default operating system.

[Lithium]

The port to Linux will facilitate a port for Android, Zilmar can raise money with a version for Android on google market.

[squall_leonhart]

Originally Posted by Lithium

The port to Linux will facilitate a port for Android, Zilmar can raise money with a version for Android on google market.

No.

-------------

[HatCat]

Originally Posted by twostars

Hmm, the only way I can think of handling that is with signals. :/

Originally Posted by zilmar

it does not check if it is rdram on not on read/writes, just executes it.

If it is not, a structured exception occurs, the structure exception handler then looks at the asm opcode causing the error, detects if it is actually in the n64 zone and maps to a n64 register address. If it does then it cause the read/write to register, setups up the x86 ops that should be filled with that value, moves EIP to the next instruction and tells the cpu to continue executing.

Not sure if that would work with signals, possible the whole memory management needs to be re-written to allow porting to linux.

I'm happy to find signals work well for me both on Linux and a 64-bit Windows 7 laptop (on a partition barely big enough to fit Windows on it, never mind pj64).

In fact, I'm not really seeing anything that the C++ try { } catch { } finally { } model is doing that the standard C approach of setting a signal ("exception") handler and doing a longjmp() when raised isn't.

[HatCat]

I wrote a program to dereference user-defined pointer ranges, that would constantly cause an access violation or a segmentation fault.

It goes something like:

#include <signal.h>
#include <setjmp.h>

int main()
{
...
    signal(SIGSEGV, exception_handler);

    for (i = 0; addr_start + i <= addr_end; i++) {
        unsigned char memory_byte;
        int recovered_from_exception;

        printf("RAM[0x%lX]:  ", addr_start + i);
        recovered_from_exception = setjmp(exc_pt);
        if (recovered_from_exception) {
            signal(SIGSEGV, exception_handler); /* Reschedule the handler. */
            continue; /* Move on to the next byte of memory in loop. */
        }
        memory_byte = *(unsigned char *)(addr_start + i); /* segfault likely */
        printf("0x%02X (%c)\n", memory_byte, memory_byte);
}

void exception_handler(int parameter)
{
    fprintf(stderr, "Exception caught (signal %i).\n", parameter);
    longjmp(exc_pt, parameter);
}

I'm not really understanding what's useful about Project64's C++ try/except/finally that can't be handled portably this way. The only exception (HAHA GET IT?) is the fact the C standard doesn't require all running environments to raise these signals automatically when you try to dereference a NULL pointer or other things. But it does work on both Windows 7 and Linux, and many of the platforms that can't or don't raise the exceptions automatically probably only support the C language and not the C++ language anyway.