#11  
Old 6th May 2013, 05:35 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

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.
Reply With Quote
  #12  
Old 7th May 2013, 12:10 AM
Lithium's Avatar
Lithium Lithium is offline
Alpha Tester
Project Supporter
Member
 
Join Date: Aug 2012
Location: hue hue br br
Posts: 68
Default

The port to Linux will facilitate a port for Android, Zilmar can raise money with a version for Android on google market.
Reply With Quote
  #13  
Old 7th May 2013, 12:21 AM
squall_leonhart's Avatar
squall_leonhart squall_leonhart is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Mar 2007
Location: Sydney, Australia
Posts: 2,911
Default

Quote:
Originally Posted by Lithium View Post
The port to Linux will facilitate a port for Android, Zilmar can raise money with a version for Android on google market.
No.

-------------
__________________

CPU:Intel Xeon x5690 @ 4.2Ghz, Mainboard:Asus Rampage III Extreme, Memory:48GB Corsair Vengeance LP 1600
Video:EVGA Geforce GTX 1080 Founders Edition, NVidia Geforce GTX 1060 Founders Edition
Monitor:ROG PG279Q, BenQ BL2211, Sound:Creative XFI Titanium Fatal1ty Pro
SDD:Crucial MX300 275, Crucial MX300 525, Crucial MX300 1000
HDD:500GB Spinpoint F3, 1TB WD Black, 2TB WD Red, 1TB WD Black
Case:NZXT Phantom 820, PSU:Seasonic X-850, OS:Windows 7 SP1
Reply With Quote
  #14  
Old 4th January 2018, 03:08 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

Quote:
Originally Posted by twostars View Post
Hmm, the only way I can think of handling that is with signals. :/
Quote:
Originally Posted by zilmar View Post
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.
Reply With Quote
  #15  
Old 4th January 2018, 03:19 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,255
Default

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:
Code:
#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.

Last edited by HatCat; 4th January 2018 at 03:28 PM.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 04:03 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.