Tuesday, September 1, 2020

Digest for comp.lang.c++@googlegroups.com - 10 updates in 7 topics

olcott <NoOne@NoWhere.com>: Sep 01 05:15PM -0500

A Universal Turing Machine (UTM) with the x86 language as its TM
description language.
 
This x86 based Universal Turing Machine (UTM) directly executes COFF
object files generated by the Microsoft "C" compiler.
 
There are two restrictions on the "C" code that can be executed in this
virtual machine:
(1) All global data must be initialized.
(2) No library function can be called.
 
The UTM environment is like a tiny little operating system here are its
only functions:
 
// allocates memory from Heap_Space
u32* Allocate(u32 size);
 
// executes a slave UTM in single step debug mode
u32 Debug_Step(u32* master_state, u32* slave_state);
 
// Saves the execution state of a UTM to state_data
u32 Save_State(u32* state_data);
 
// Loads the execution state of a UTM from state_data
u32 Load_State(u32* state_data);
 
When a UTM is running the execution trace of each assembly language
instruction / operating system function call is provided.
 
After each Debug_Step() virtual machine instruction is executed the
Master UTM can examine the machine state of the Slave UTM.
 
The recursion depth of UTMs executing other UTMs in Debug-Step mode is
of arbitrary depth.
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 01 05:09PM -0500

A Universal Turing Machine (UTM) with the x86 language as its TM
description language.
 
This x86 based Universal Turing Machine (UTM) directly executes COFF
object files generated by the Microsoft "C" compiler.
 
There are two restrictions on the "C" code that can be executed in this
virtual machine:
(1) All global data must be initialized.
(2) No library function can be called.
 
The UTM environment is like a tiny little operating system here are its
only functions:
 
// allocates memory from Heap_Space.
u32* Allocate(u32 size);
 
// executes a slave UTM in single step debug mode
u32 Debug_Step(u32* master_state, u32* slave_state);
 
// Saves the execution state of a UTM to state_data
u32 Save_State(u32* state_data);
 
// Loads the execution state of a UTM from state_data
u32 Load_State(u32* state_data);
 
When a UTM is running the execution trace of each assembly language
instruction / operating system function call is provided.
After each Debug_Step() virtual machine instruction is executed the
Master UTM can examine the machine state of the Slave UTM.
 
--
Copyright 2020 Pete Olcott
Juha Nieminen <nospam@thanks.invalid>: Sep 01 09:13AM

> (Not that it seemed toxic or anything; it was just a very depressing
> ghost of a newsgroup.)
 
Nowadays usenet is mostly dead anyway. This group might be one of the last
dinosaurs still alive and kicking. Expect it to die within a decade, though.
 
(Not that I consider it a good thing. Just making an observation.)
boltar@nuttyella.co.uk: Sep 01 09:24AM

On Tue, 1 Sep 2020 09:13:46 +0000 (UTC)
>Nowadays usenet is mostly dead anyway. This group might be one of the last
>dinosaurs still alive and kicking. Expect it to die within a decade, though.
 
>(Not that I consider it a good thing. Just making an observation.)
 
People were saying that 10 years ago. Usenet won't die until either all the
NNTP servers vanish or the people still using it finally die. I suspect the
former will come first as there arn't many now as it is.
 
Also plenty of the uk.* groups are still well used.
olcott <NoOne@NoWhere.com>: Sep 01 05:00PM -0500

On 9/1/2020 3:39 PM, Mike Terry wrote:
 
> The "or at least" seems to be PO recognising that H is not in fact shown
> to be a complete decider - all it would mean is that one argument
> showing it to be incomplete has been refuted.
 
It empirically shows that every self-referential halting problem
counter-example that "proves" that halting is undecidable has been refuted.
 
Here is how I summed up your analysis:
Every x86 program that terminates has a Turing Machine equivalent.
 
It is identical to my intuition from 2018, yet now I have someone that
agrees and a process for proving that it is true rather than merely a
hypothesis.
 
A "C" program maps to an x86 program that maps to a model of computation
that is provably equivalent to a Turing machine, therefore "C" programs
and x86 programs have equivalent TMs.
 
The key thing that I wanted to be certain of was that there were zero
cases where a Turing machine derived a different result than a "C"
porgram or an x86 program on equivalent input.
 
So now I have an analytical chain-of-inference that proves that all "C"
programs and x86 programs that terminate have equivalent (functionally
identical) Turing machines, thus for all practical purposes are
one-and-the-same thing as an actual Turing machine for specific
computations.
 
Bottom line this means that my halting problem refutation would apply to
Turing machines.
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 01 03:08PM -0500

Turing equivalent x86 computations are defined as:
(a) An x86 program can be translated into an abstract model of
computation that is provably equivalent to a Turing machine.
 
(b) The abstract model of computation can be concretely implemented on
physical hardware.
 
(c) All computations performed on the concrete implementation have an
identical (state-change-by-state-change and
tape-head-move-by-tape-head-move) execution traces between the abstract
model and its concrete implementation for all computations not requiring
more memory than is available.
 
This would guarantee that the execution of an x86 program on an input
would be equivalent to the execution of a Turing machine on equivalent
input for all x86 programs that complete executing and halt.
 
The Church-Turing thesis makes no such guarantee:
https://plato.stanford.edu/entries/church-turing/
 
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 01 11:10AM -0500

Turing equivalent x86 computations are defined as:
(a) An x86 program can be translated into an abstract model of
computation that is provably equivalent to a Turing machine.
 
(b) The abstract model of computation can be concretely implemented on
physical hardware.
 
(c) All computations performed on the concrete implementation have an
identical (state-change-by-state-change and
tape-head-move-by-tape-head-move) execution trace between the abstract
model and its concrete implementation for all computations not requiring
more memory than is available.
 
Applying this same reasoning to my x86-UTM shows that many computations
performed by the x86 based UTM are equivalent to computations on an
actual UTM.
 
Besides memory allocation from the heap the x86-UTM provides a virtual
machine instruction allowing any UTM to execute another UTM in
debug-step mode. This recursive invocation can be to an arbitrary
recursive depth.
 
UTMs can be written in Microsoft "C". The resulting COFF object file can
be directly executed by the x86-UTM. All global data must be
initialized. All global data references in the code section are patched
to refer to their offset in the COFF data section. Execution uses the
flat 32-bit model.
 
The x86 based UTM will be posted to a code repository as open source
with a very permissive license.
 
--
Copyright 2020 Pete Olcott
olcott <NoOne@NoWhere.com>: Sep 01 11:51AM -0500

On 9/1/2020 11:10 AM, olcott wrote:
 
> UTMs can be written in Microsoft "C". The resulting COFF object file can
> be directly executed by the x86-UTM. All global data must be
> initialized.
 
No library functions can be called. Uninitialized global data and
library function calls produce an error message.
 
 
--
Copyright 2020 Pete Olcott
boltar@nuttyella.co.uk: Sep 01 09:22AM

On Mon, 31 Aug 2020 22:50:07 +0200
 
>You missed the bit where I pointed out how utterly useless these figures
>are. If you knew the first thing about what you were doing, you'd
>understand that already.
 
You really are a class act:
1) Make assertion, don't back it up.
2) Oh ok, you'll back it up with some figures under duress.
3) Assertion proven false.
4) Claim figures were rubbish anyway
 
You should go into politics.
"The Doctor" <doctor@doctor.nl2k.ab.ca>: Sep 01 07:17AM

XanaNews Statistic for comp.lang.c++. 9/1/2020 1:17:12 AM
 
From article 417546 (8/1/2020 4:52:10 AM) to article 418052 (8/31/2020
3:34:48 PM)
 
Number of threads ................... 33
Number of articles .................. 509
Average articles per thread ......... 15.42
Number of unanswered posts .......... 6
Number of posts from XanaNews users .. 1
 
 
Top Threads
 
Ranking Articles Subject
------- -------- ----------------------------------
1 86 Are there any asm-instructions to support OOP
2 72 incompatible types in assignment
3 60 Does std::regex need to be so large?
4 40 Worst thing about 2020 C++
5 27 Can similar programs be legel, warning or error?
6 24 Using floating-point math to do integral sqrt
7 22 Re: Are bitfields useful?
8 20 "C++ Creator Bjarne Stroustrup Weighs in on
Distributed Systems, Type Safety and Rust"
9 17 Porting C++ code to C
10 13 Strip Whitespace
11 13 Initialising a thread_local object with ID of thread
12 12 Dark theme?
13 11 Preprocessor output into Class processor
14 11 Transforming "C" into a Turing equivalent language
001 [Providing unlimited memory access to C]
15 11 Three 8-hour days on cmake
16 10 Putting a function in shared memory
17 9 static initialisation fiasco
18 8 "Address Sanitizer in Visual C++" by Shao Voon Wong
19 7 Call destructor on object of any type
20 6 Porting polymorphic classes from C++ to C
21 5 removing items (strings) from vector<string>
22 5 Re: Simply defining Gödel Incompleteness and Tarski
Undefinability away V52 (Machine equivalence)
23 5 [OT] An if any and if all blocks
24 3 Re: Observable end padding in arrays
25 2 Declaring template member of template class a friend
26 2 Avoid excessive write cycles to block
27 2 Re: TRACE produces nothing
 
 
Top Posters
 
Ranking Articles Name Most Used Newsreader
------- -------- -------------------------- --------------------
1 50 Juha Nieminen tin
2 32 David Brown Mozilla
3 31 Chris M. Thomasson Mozilla
4 30 boltar@nuttyella.co.uk
5 25 Frederick Gotham G2
6 23 Bonita Montero Mozilla
7 23 RM Mozilla
8 21 James Kuyper Mozilla
9 20 Jorgen Grahn slrn
10 19 Sam http:
11 15 Alf P. Steinbach Mozilla
12 14 Öö Tiib G2
13 12 olcott Mozilla
14 11 Scott Newman Mozilla
15 11 wyniijj@gmail.com G2
16 11 Paavo Helde Mozilla
17 11 boltar@nowhere.co.uk
18 9 Vir Campestris Mozilla
19 9 Mr Flibble Mozilla
20 7 Lynn McGuire Mozilla
21 7 Cholo Lennon Mozilla
22 7 Bo Persson Mozilla
23 6 Chris Vine Sylpheed
24 6 jacobnavia Mozilla
25 6 Christian Gollwitzer Mozilla
26 5 Tim Rentsch Gnus
27 5 rick.c.hodgin@gmail.com G2
28 5 daniel...@gmail.com G2
29 5 Richard trn
30 4 Barry Schwarz Forte Agent
31 4 Stefan Monnier Gnus
32 4 Brian Wood G2
33 4 Ben Bacarisse
34 3 Siri Cruise MT-NewsWatcher
35 3 Ian Collins Mozilla
36 3 Manfred Mozilla
37 3 Keith Thompson Gnus
38 3 Mike Copeland MicroPlanet-Gravity
39 3 Stefan Ram
40 3 Terje Mathisen Mozilla
41 3 red floyd Mozilla
42 3 Bart Mozilla
43 3 woodbrian77@gmail.com G2
44 2 Andrey Tarasevich Mozilla
45 2 Christian Hanné Mozilla
46 2 Stephen Fuld Mozilla
47 2 Melzzzzz slrn
48 2 Mike Terry Mozilla
49 1 The Doctor XanaNews
50 1 Kaz Kylheku slrn
51 1 Richard Damon Mozilla
52 1 Torbjorn Lindgren trn
53 1 Jean-Marc Bourguet
54 1 mac NewsTap
55 1 Rick C. Hodgin Mozilla
56 1 Daniel P G2
57 1 Daniel Hyde Mozilla
58 1 Nikki Locke Nikkis auto poster
59 1 thomas.healy1987@gmail.com G2
60 1 Ike Naar slrn
61 1 Ivan Godard Mozilla
62 1 Real Troll
63 1 boltartoyou@nuttyella.co.u
 
 
Top Newsreaders
 
Ranking Articles Newsreader Users
------- -------- -------------------------------------------- -----
1 253 Mozilla 29
2 73 G2 10
3 51 <unknown> 7
4 50 tin 1
5 24 slrn 4
6 19 http: 1
7 12 Gnus 3
8 6 trn 2
9 6 Sylpheed 1
10 4 Forte Agent 1
11 3 MT-NewsWatcher 1
12 3 MicroPlanet-Gravity 1
13 1 NewsTap 1
14 1 Nikkis auto poster 1
15 1 XanaNews 1
 
 
--
This email has been checked for viruses by AVG.
https://www.avg.com
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)