- neoGFX Design Studio - 1 Update
- Change - 1 Update
- Mapping "C" to a Turing equivalent abstract model of computation - 4 Updates
- Bit Swizzling (c++ versus c) - 1 Update
- Bit Swizzling - 3 Updates
- Clarification of PO's UTM architecture and his H and H_Hat - 1 Update
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 09 12:00AM +0100 Hi! Work has begun in earnest on neoGFX Design Studio: https://neogfx.org/images/designstudio.png /Flibble -- ¬ |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 08 11:29PM +0100 https://www.youtube.com/watch?v=ayDWlNqQyJg&fbclid=IwAR1BETwpmJIp8kcYV2r1kKtsQ6sk3ljB9wUT1N75YR_9e2lJvxQjxdx7kZ8 -- |
| Jeff Barnett <jbb@notatt.com>: Sep 08 11:18AM -0600 On 9/5/2020 10:38 AM, olcott wrote: Suggestion for you, our resident dunce: Use Lisp, not C. Writing a TM interpreter is basically a homework problem I know it may still be difficult for you but it will save another 16 years. Here is a list of some available implementations. Note, some of these are time-limited URL because their authors put them in a public place so they could be reached. I really don't expect you to pay any attention to all of this but it could save you decades. I'm not sure what you will do with your time after this project is over via failure. https://github.com/fmdkdd/turisp (CL) http://www.lysator.liu.se/~davidk/elisp/turing.el (GNU ELISP) https://github.com/dieggsy/turing-machine (GNU ELISP + GNU emacs interface) https://drive.google.com/file/d/1DUCuwaVR5ElQSD8poKfxRXmmLjNprkJF/view?usp=sharing https://ln.sync.com/dl/5a02647d0/75mxr3ta-n9ymydu2-su64kn7p-wdjtzb4p You can even find UTM code TM form in some books or, perhaps, on the internet. Perhaps, Ben can give you a pointer - it's been too long ago for me. -- Jeff Barnett |
| olcott <NoOne@NoWhere.com>: Sep 08 12:30PM -0500 On 9/8/2020 12:18 PM, Jeff Barnett wrote: > You can even find UTM code TM form in some books or, perhaps, on the > internet. Perhaps, Ben can give you a pointer - it's been too long ago > for me. Using the RASP equivalent model of the x86 programing language is most effective because this model hands me all of the control flow of the entire system as a fully encoded directed graph. When creating a halt decider it is very handy to have all of control flow already encoded as a directed graph. It is also very handy because all the code that derives this directed graph can be specified as the high level abstraction of the "C" programming language. How much easier is it to understand the architecture of a system specified in "C" than it would be to examine this same architecture on the basis of (TM 5-tuple) microcode? -- Copyright 2020 Pete Olcott |
| Jeff Barnett <jbb@notatt.com>: Sep 08 02:48PM -0600 On 9/8/2020 11:30 AM, olcott wrote: > How much easier is it to understand the architecture of a system > specified in "C" than it would be to examine this same architecture on > the basis of (TM 5-tuple) microcode? Gibberish. Your just stalling. -- Jeff Barnett |
| olcott <NoOne@NoWhere.com>: Sep 08 04:34PM -0500 On 9/8/2020 3:48 PM, Jeff Barnett wrote: >> specified in "C" than it would be to examine this same architecture on >> the basis of (TM 5-tuple) microcode? > Gibberish. Your just stalling. Ben backed out of an equivalent claim going so far as to say that he never made any such claim. This is my x86utm operating system interface: It is very close to fully operational. // Saves the state of the current virtual-machine void SaveState(u32* s); // Loads the state of a saved virtual-machine void LoadState(u32* s); // Allocates memory from the heap u32* Allocate(u32 size); // The master machine executes the slave machine void DebugStep(u32* master_state, u32* slave_state); -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Sep 08 02:59PM -0500 On 9/8/2020 11:17 AM, Rick C. Hodgin wrote: > and computer-controlled welding. > I've always been weak on C++ because it's so big and complex and I > have preferred C code 10:1 over C++ code for general coding styles. I focused on learning the subset of c++ the most directly enabled me to write much better code. I learned "c" on the basis of K&R because it was the only standard available at the time and met Bjarne Stroustrup we he came to Omaha to promote his new C++ language. He is a tee-shirt and blue jeans kind of guy. If you only learn the c++ classes of the object oriented programming model and two items of the standard template library you will know all the c++ that you ever really need to make the same programs you make in "c" much easier to understand and maintain. I mostly only use the std::vector and the std::string aspect of the standard template library. In my whole life the only dynamic memory allocation that I ever used in any of my programs is std::vector. The key advantage of the oriented programming model when used effectively is that it totally eliminates data dependencies. Another advantage based on the same idea is the cognitive leverage that this extra degrees of modularity provides. All of the functionality and data is in the same place. |
| olcott <NoOne@NoWhere.com>: Sep 08 01:09PM -0500 On 9/8/2020 12:53 PM, Bonita Montero wrote: >> into their constituent parts. > Parentheses make the code less readable if you know the operator > precedence. If complex expressions are encoded as a hierarchy of appropriately named compile time macros parenthetical expression nesting is greatly reduced. I have found that it is best to make code directly say what you mean and not have to separately remember language details that can possibly vary across languages. -- Copyright 2020 Pete Olcott |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 08 08:44PM +0200 > If complex expressions are encoded as a hierarchy of appropriately named > compile time macros parenthetical expression nesting is greatly reduced. That's a totally different discussion. |
| Kaz Kylheku <793-849-0957@kylheku.com>: Sep 08 06:48PM >> precedence. > If complex expressions are encoded as a hierarchy of appropriately named > compile time macros parenthetical expression nesting is greatly reduced. See, if you just avoid topics of Turing and Halting, you start to make sense. You should do that more often. You could teach children computing principles or something. > I have found that it is best to make code directly say what you mean and > not have to separately remember language details that can possibly vary > across languages. That's a great point; I was also thinking of the same thing. Suppose you're a busy developer working on tasks in four different languages in the same day. You can get tripped up; your wires can get crossed. By and large, languages broadly agree on only the "BEDMAS" precedence rules everyone learns in elementary school. For other operators that language designers have invented, there is a large variance in precedences and other details. (Not all languages, have BEDMAS, either. Smalltalk is an example of a language in which operators are reduced left to right, because they are just method application, or something like that: x + y * z means (x + y) * x). |
| olcott <NoOne@NoWhere.com>: Sep 07 07:45PM -0500 On 9/7/2020 7:07 PM, Andy Walker wrote: > produced simpler and independent proofs. Appel and Haken are still > universally acknowledged; if they had waited, others might easily > have got in first. I may pre-publish the essence of my work through email to a few comp theory college professors. The email should sufficiently establish an audit trail. Now that I am so close to finishing I am sure that a summation of this work would be construed as establishing priority at least in light of the very soon to be completed work. > If you want to publish while retaining "trade secrets", you > may recall the 17thC precedent of [eg] Hooke publishing his law in > the form of an anagram. I may be able to publish everything except a PhD level quality verbiage by next month. Since my code will fully speak for itself not having the best words to describe it will merely delay academic publication and thus have no lasting impact. I may have something like 1500 hours in my x86 based UTM equivalent. At least two months of that work (trying to do everything from scratch) was discarded. My x86utm has the superb basis of a really well written x86 emulator that was written by a team of highly skilled developers over several decades. It fully implements the both the 16-bit and 32-bit entire basic instruction set of the Intel x86 language and no more. I developed a COFF library for it so that the slightly enhanced system can directly execute the COFF object files generated by the Microsoft "C" compiler. It will probably also directly execute COFF object files targeted for x86 by GCC. I am focusing on the Microsoft "C" because it generates code that is easier to understand. x86utm is concurrently implemented on both Windows and Linux. It will be published as open source. I may also make x86utm into a web-service. -- 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