> Robin Vowels wrote: > That's of consequence, as a number of such instructions > can be strung together to deal with strings longer than 256 characters.
Really!!! This is your takeaway from what I wrote? The C example was to deal with each of the 256 bytes (not as a single string). There were other comments about similar non-sense. Regards, Jon. On Monday, February 5, 2018 11:25 PM, Robin Vowels <robi...@dodo.com.au> wrote: From: "Jon Perryman" <jperr...@pacbell.net> > This is too funny. Profess the virtues of C and provide actual examples that > look like they prove > the point but when scrutinized actually disprove it. When I provided these > type of examples, it > was considered a gross exaggeration. C is a mindset that is common. Here's > the proof I'm not > exagerating at all. > >> Kirk Wolf wrote: >> If you compile this with full optimization and look at the generated >> assembly, you will find a fancy unrolled loop. >> Who knows if MVCIN is any faster? It certainly won't handle len>256 cases. > > This statement would be funny if it weren't so sad. The "fancy" loop would be > a simple loop to > move each byte where the second operand starts at the end. "optimization" > never recognized this > as an MVCIN loop but it really optimized the code it produced. MVCIN is > obviously many times > faster than a single byte loop to move each character (how can this even be a > question). Can > anyone tell us how many times faster MVC 256 bytes is than 256 MVC 1 byte? > To really prove C is superior, MVCIN is limited to 256 byte moves. That's of no consequence, as a number of such instructions can be strung together to deal with strings longer than 256 characters. But wasn't the instruction intended just for printing? In which case, the length of the string will be of the order of 100 or so. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
