[Wrong section] why not static recompiling?
#11
Thank you Leaper. Really thank you Smile

(11-03-2013, 05:35 PM)Leaper Wrote: Anyways you approach is moving towards basically embedding an interpreter inside of the executable, with all the shortcomings of interpretation (speed, etc) and way messier implementation, than just interpreter + original code pair.

The interpretator is just for the LLVM, to follow the started example. You can delete that part.

(11-03-2013, 05:35 PM)Leaper Wrote: With self modifying code it is usually hard to know what the value of the modification will be (i.e. you don't know statically what 'b' is). That value can come from external sources (e.g. files), or it can come through some complicated code sequence, such that you cannot trace it back, or it can take on many values based on other runtime values.

Yes, but if PSX assembly can handle files, also x86 assembly should, right?
I load the file and than I manage its data.
Basically I want to demostrate that an assembly can be transformed in another assembly.
I think it's an important question that will let me understand the CPUs better and gave me a better tecnical preparation. That's why is so important to me.

(11-03-2013, 05:35 PM)Leaper Wrote: Hence for your approach to work you would need to wrap every memory write in some code to correctly replace 'a' with 'b'. Also not all memory writes are modifying code, so you would need to be able to figure out, when write modifies code or data.

But i CAN wrap every memory write in some code, right?
At least one wrapper each istruction, but it shouldn't be difficoult.

Thank you again
(write me soon, boss Laugh)

Max
Reply

Sponsored links

#12
Static recompilation is by definition a process that does translation of code once, prior to ever running it. The file example was just meant to point out that with self modifying code there are cases where the correct translation cannot be determined until code is run. The are many other such cases beyond files. Yes, you can add all the extra runtime handling you described and it would work, but then it is not really a static recompilation and really more like an interpreter inside embedded recompiled assembly.
Reply
#13
(11-06-2013, 07:55 AM)Leaper Wrote: Static recompilation is by definition a process that does translation of code once, prior to ever running it. The file example was just meant to point out that with self modifying code there are cases where the correct translation cannot be determined until code is run. The are many other such cases beyond files. Yes, you can add all the extra runtime handling you described and it would work, but then it is not really a static recompilation and really more like an interpreter inside embedded recompiled assembly.

Leaper you win.

I'm really happy that you said my idea would work. It's not a real static recompilation but it's ok. However I think my concept is quite correct, be able to handle a foreign assembly without dynamic recompiler or interpreters.
I think this will help me a lot.

Thank you so much for the explanation.
I hope to write you soon Laugh

Max
Reply
#14
It would work maybe yes, but it would be slow, interpreters are always slow. Dynamic recompilation is really the best option.
[Image: ref-sig-anim.gif]

Reply
#15
(11-06-2013, 04:58 PM)refraction Wrote: It would work maybe yes, but it would be slow, interpreters are always slow. Dynamic recompilation is really the best option.

It is not 'a sort of interpetation' but 'a sort of static recompiler' u.u
Practically thare is no difference but I prefer the second noun. I'm very proud of that Happy

Obviously that 'function pot' has not-so-fast performance. It has like 3x lines of the original source, it's full of jump and so.

But now I can say I designed a concept for 'a sort of static recompiler', which is a very good thing for a newbie like me, because it means I understood and avoided the problem of self modifing code.

OT It is twice a good thing because my high school thesis will be on self modifing code. I think nobody in my school have done anything similar in 30 years, so I'm very proud.

Maybe i will implement this concept for an EASY cpu (NES isn't too difficoult in my opinion, and usually nes application are full of self modifing code and tricks). I will say you if it works Smile
Reply
#16
Well wait a minute. Just an explanation.

My concept work like this (imagine the PSX assembly has 200 instruction)
1) I make 200 wrapper function
2) I rebuild the code as it was originally

It doesn't matter where self modifing code come from (like a file or a sequence of istruction)

Semplified example:
PSX:
190: a = readFile();
191: *(192) = a;
192: NOP

PC:
190: a = readFileWrapper()
191: *(192) = a;
192: NOP

It has like the same assembly. It has ALWAYS the same assembly. Just it load 'a' when it reads the file, but it is like in the old file.

In the code segment the application will substitute the NOP with the 'a' function. Like in the original assembly.
Reply
#17
(11-06-2013, 09:54 PM)ignus879 Wrote: Well wait a minute. Just an explanation.

My concept work like this (imagine the PSX assembly has 200 instruction)
1) I make 200 wrapper function
2) I rebuild the code as it was originally

It doesn't matter where self modifing code come from (like a file or a sequence of istruction)

Semplified example:
PSX:
190: a = readFile();
191: *(192) = a;
192: NOP

PC:
190: a = readFileWrapper()
191: *(192) = a;
192: NOP

It has like the same assembly. It has ALWAYS the same assembly. Just it load 'a' when it reads the file, but it is like in the old file.

In the code segment the application will substitute the NOP with the 'a' function. Like in the original assembly.

Looks like assembly became a high level language, even hardware independent Smile

Edit: Just to dirty and quick reference, source wiki http://en.wikipedia.org/wiki/X86_assembly_language
Code:
.model small
.stack 100h

.data
msg     db      'Hello world!$'

.code
start:
        mov     ah, 09h   ; Display the message
        lea     dx, msg
        int     21h
        mov     ax, 4C00h  ; Terminate the executable
        int     21h

end start

From the above look how many differences are in the coding of the same thing using assemblies for different OS, different assemblers or even if going to call high level routines.

The above example supposes int 21h (09h) points to a vector to display a buffer, something hardware dependent that one can't take for sure.
Imagination is where we are truly real
Reply
#18
(11-07-2013, 11:22 AM)nosisab Ken Keleh Wrote: Looks like assembly became a high level language, even hardware independent Smile

It was just an example to help people understand my idea.
Look at the xsl file, it has a more realistic concept written in a simil-assembly
Reply
#19
Someone got SMB1 working.
Quote:After completing this project, I believe that static recompilation does not have a practical application for video game emulation.
Reply
#20
Interresting.
Reply




Users browsing this thread: 1 Guest(s)