| olcott <NoOne@NoWhere.com>: Oct 20 11:33AM -0500 x86utm is as much as possible a Universal Turing Machine UTM that has the x86 language as its Turing Machine Description language. It is common knowledge that the RASP architecture is equivalent to a universal Turing machine. It is self-evident that the x86 language is a finite implementation of the Random Access Stored Program (RASP) model. x86 UTM has these four key operating system functions providing the functionality to transform an x86 emulator into a finite Universal Turing Machine: (Source code will be provided) u32* Allocate(u32 size); // Allocate bytes of memory void SaveState(Registers* state); void LoadState(Registers* state); u32 DebugStep(Registers* master_state, Registers* slave_state); To make x86utm easy to use it directly executes the COFF object file output of the Microsoft C compiler. The entire x86UTM system works on both Windows and Linux. It will also directly execute the output of the GCC compiler when this output has been converted to the COFF format. An open source utility is provided for this purpose. x86utm is based on a very superb x86 emulator. The only change the needed to be made to the emulator was to very slightly adapt it to compile under windows and add the feature of disassembling an object file. All of the adaptations to transform this emulator into a master UTM are contained in a single C++ source file. Here is how x86UTM is applied to the Peter Linz H() and H_Hat() to correctly decide halting of H_Hat() H() continues to DebugStep() though H_Hat() until H_Hat() terminates or H() decides that H_Hat() would not otherwise terminate. In this case H() would stop executing H_Hat() and report Not_Halting behavior. H() executes H_Hat() as if H() was a UTM. H() and H_Hat() are separate processes having their own: {Memory, registers and stack} To make things simple the halt deciding aspect of H() and H_Hat() is the same function. (see below) #define HALT __asm hlt // N and M have address of H_Hat() int H(u32 M, u32 N) { int Abort = DebugTrace(M, N); if (Abort) { MOV_EAX_0 HALT } else { MOV_EAX_1 HALT } } int main() { u32 M = (u32)H_Hat; H(M, M); HALT; } -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 20 07:11PM +0100 On 20/10/2020 17:33, olcott wrote: > processes having their own: {Memory, registers and stack} > To make things simple the halt deciding aspect of H() and H_Hat() is the > same function. (see below) So what is this "the same function"? It looks like that function is DebugTrace(), right? (A better name might be Decide(), which expresses its role in the program, but no biggie.) |
| olcott <NoOne@NoWhere.com>: Oct 20 01:40PM -0500 On 10/20/2020 1:11 PM, Mike Terry wrote: > So what is this "the same function"? It looks like that function is > DebugTrace(), right? (A better name might be Decide(), which expresses > its role in the program, but no biggie.) Both H() and H_Hat() invoke the same DebugTrace() function. DebugTrace() continues a DebugStep() of M(N) unless M(N) would not otherwise terminate. At the first point that DebugTrace() determines that M(N) would not otherwise terminate it aborts the DebugStep() of M(N). - #define MOV_EAX_0 __asm mov eax,0 - #define MOV_EAX_1 __asm mov eax,1 - #define HALT __asm hlt - // N and M have the address of H_Hat() - int H(u32 M, u32 N) - { - int Abort = DebugTrace(M, N); - if (Abort) - { - MOV_EAX_0 // M(N) would not otherwise terminate - HALT - } - else - { - MOV_EAX_1 // M(N) has terminated - HALT - } - } - - - int main() - { - u32 M = (u32)H_Hat; - H(M, M); - HALT; - } -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 20 02:19PM -0500 On 10/20/2020 1:40 PM, olcott wrote: > - H(M, M); > - HALT; > - } All of the Input pairs {M, N} to H() that actually halt reach MOV_EAX_1 // M(N) has terminated All of the Input pairs {M, N} to H() that are decided would not otherwise halt reach MOV_EAX_0 // M(N) would not otherwise terminate Although there may be some cases that are very difficult to decide there are no cases left that are impossible to decide. -- Copyright 2020 Pete Olcott |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 20 02:26PM -0700 On 10/20/2020 11:40 AM, olcott wrote: > otherwise terminate. > At the first point that DebugTrace() determines that M(N) would not > otherwise terminate it aborts the DebugStep() of M(N). How does it determine that an unknown function will never terminate? |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 14 08:05PM On Sun, 2020-10-11, Öö Tiib wrote: > own issues. > Program is put together of patterns and it is business of compiler > to reduce it to minimal binary code. It's not how I see it, but I couldn't come up with a good explanation of how I /do/ see it. >> types. > May be it is indeed better to use unordered_map<std::string, Photo>. > I think of such idiom as "dictionary idiom" as it is rather common. For me, anything that discourages use of domain-specific types is a bad thing. I use them a lot to (the way I see it) make my designs clearer; it's one of the main benefits of C++ IMO. > That does compile when <string> is included. What you search > for photo in your set of photos with? Without file name in > external interface? Dummy photo? In this application, a (name of a) photo isn't just a string: it's either a file name matching a certain pattern, or it's invalid. I establish that at the external interface, before this set or map gets involved. Then it makes sense to represent it as a type, to show that this invariant holds. [snip] /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| olcott <NoOne@NoWhere.com>: Oct 17 09:58AM -0500 On 10/17/2020 8:33 AM, André G. Isaak wrote: >> in theory T. > You don't "stipulate" a proposition to be undecidable. It either is or > it isn't. This: (T ⊬ φ) and (T ⊬ ¬φ) is stipulated to define the concept of undecidable proposition. Symbols only have meanings when meanings have been assigned to them. > concerned, we've only identified a tiny fraction of the undecidable > propositions. Because there is no general method for deciding whether a > proposition is decidable, most will never be identified. When we determine that every single undecidable proposition known or unknown proven or unproven is only undecidable because it is incorrect then we have covered ALL of them with NONE left out. When we do this then every single proof of incompleteness that depends on undecidable propositions utterly fails. For the same reason that we cannot decide that a medical doctor is "incompetent" in the basis of their inability to restore health to the cremated** we cannot decide that a formal system is "incomplete" on the basis of it inability to prove or disprove incorrect expressions of language. ** Even Christ never did that. > still leaves you with all of the unknown examples of undecidable > propositions, which means the system remains incomplete. > André When we rename the whole category of "undecidable proposition" to "incorrect proposition" then there are zero undecidable propositions left to prove incompleteness. -- Copyright 2020 Pete Olcott |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment