From:  "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date:  16 Oct 2024 11:57:35 Hong Kong Time
Newsgroup:  news.alt119.net/comp.lang.c
Subject:  

Re: ChatGPT explains why rebuttals of my work are incorrect

NNTP-Posting-Host:  null

On 10/15/2024 6:37 PM, Mike Terry wrote:
> On 15/10/2024 20:40, Chris M. Thomasson wrote:
>> On 10/15/2024 9:06 AM, Mike Terry wrote:
>> [...]
>>>> _______________________
>>>
>>> You seem to be compiling the wrong program.  The source code is 
>>> halt7.c and has nothing to do with ct_threads.
>>
>> Shit happens Mike, sorry about that. Anyway, it compiles with C for x86:
>>
>> https://i.ibb.co/1bKYQMv/image.png
>>
>> but crashes during a run:
>>
>> https://i.ibb.co/T0f1Wjg/image.png
>>
>> The call stack for the error is:
>>
>>  >    ct_thread_playground.exe!Init_Halts_HH(unsigned int * * Aborted, 
>> unsigned int * * execution_trace, Decoded * * decoded, unsigned int * 
>> code_end, unsigned int P, x86_Registers * * master_state, 
>> x86_Registers * * slave_state, unsigned int * * slave_stack) Line 
>> 544    C
>>       ct_thread_playground.exe!H(void(*)() P, void(*)() I) Line 701    C
>>       ct_thread_playground.exe!D(int(*)() M) Line 1369    C
>>       ct_thread_playground.exe!main(...) Line 1376    C
>>       ct_thread_playground.exe!invoke_main() Line 78    C++
>>       ct_thread_playground.exe!__scrt_common_main_seh() Line 288    C++
>>       ct_thread_playground.exe!__scrt_common_main() Line 331    C++
>>       ct_thread_playground.exe!mainCRTStartup(void * __formal) Line 
>> 17    C++
>>       kernel32.dll!74d17ba9()    Unknown
>>       [Frames below may be incorrect and/or missing, no symbols loaded 
>> for kernel32.dll]
>>       ntdll.dll!76fdc0cb()    Unknown
>>       ntdll.dll!76fdc04f()    Unknown
>>
> 
> It looks like you've compiled halt7.c and linked it to form an 
> executable, then you're running that executable as an OS process?  
> That's not what you need to do.
> 
> halt7.c needs to be compiled to halt7.obj (assuming Windows) which is a 
> COFF file.  You've done that bit.  The halt7.obj file is passed as a 
> parameter to PO's x86utm.exe, whichx reads the COFF file as input data, 
> and provides a virtual x86 environment in which to "run" the obj code.  
> I'm actually a bit surprised that you were able to link halt7.obj to 
> create an executable!
> 
> So if you want to try out the code in halt7.c, you will need to build 
> x86utm.exe, which provides the virtual environment in which it "runs".  
> The source on Github has all the source, including the PO-written code 
> and the code coming from libx86emu, which is the x86 emulation software 
> PO uses. There is a MSVS project file to do the build, or you could 
> compile/link the files manually if you had to.  There are 6 C 
> compilation units (from libx86emu) and 1 C++ compilation unit 
> (x86utm.xpp). I think the code is written as 32-bit.  (Obviously you 
> need the header files also on Github.)
> 
> So the process you will run in your debugger is x86utm.exe.  That makes 
> it tricky to "step through" halt7.c code, since halt7.c code is just 
> data being manipulated within the x86utm process.
> 
> The reason you can't just link halt7.c to an OS executable and run it is 
> that it is full of calls to "primitive" ops like Allocate() and 
> DebugStep() which are intercepted by x86utm.exe and processed within 
> x86utm.  Like a supervisor call mechanism.

ahhh! Thanks you for the heads up Mike! Thanks.