[Coco] Need some advice

Sat May 21 23:10:12 EDT 2016

When I wrote Supercomm over 25 years ago the primary impetus was to have an OS9 terminal program that could download via xmodem and ymodem significantly faster than a popular program that was then available which was written in C.  Certain persons on Delphi and Compuserve chided me and said that a communications program written in C would be every bit as fast as one written in assembler.  Back then time was money.  Many BBSs were long distance calls and we paid by the minute.  So, I did some tests.  I wrote what eventually became Supercomm and compared it against the program which was written in C.  At the time, I realized speed improvements somewhere in the neighborhood of 10%, as I recall, when downloading files from the same BBS with the same modem.  I concluded that part of the reason  was more optimized code from writing in assembler as well as calculating checksum on the fly instead at the end of each received block.  With the advent of faster processors and better C compilers I'm sure that the gap between assemblers and C compilers has narrowed.

Dave Philipsen

> On May 21, 2016, at 10:53 AM, Greg <glaw at live.com> wrote:
> 
> It's very common practice for C (and other) compilers to store local (non-blob) variables on the stack and global variables (and local blob variables) in the heap. This provides a significant advantage because cleaning up local storage is easy as LEAS 8,S followed by an RTS (e.g. it's really fast and easy) and it helps prevent fragmentation of the heap. Heap fragmentation has always been a pain to deal with because it requires tracking free blocks and complex (and potentially slow) algorithms to attempt to fill the heap optimally (hence all the various flavors of the malloc algorithm).
> 
> Imagine you call a method that that needs 8 bytes for local variable storage and local variable storage is allocated on the heap. If this method allocates a 256 buffer and then returns, you now have an 8-byte hole in the heap between the last allocation and the 256-byte buffer. If you now need to allocate a 6-byte array, the compiler has two choices: 1) find the first block on the heap big enough to store the array and use it, or 2) find the smallest block on the heap big enough for the array and use it. The first option is the fastest but it results in increased heap fragmentation while the second option attempts to minimize heap fragmentation as best it can.
> 
> This can be critically important because compilers can't defragment the heap so you may end up in a situation in which you can no longer allocate the memory you need even with 8K free heap -- because that 8K free heap is in lots of free blocks that are too small for your needs.
> 
> *Compilers that rely on a virtual machine with gobs of memory (like Java and C#) can defragment the heap, but this can be a very slow process and it requires huge blocks of memory to track all the pointers.
> 
>> On 5/21/2016 10:43:04 AM, "Bill Pierce via Coco" <coco at maltedmedia.com> wrote:
>> 
>> Actually, the OS9 C compiler writes pretty fast code. I have done a few experiments with asm and C in OS9 and the results were pretty impressive.
>> The largest "overhead" in C is the fact that C passes all variables (no matter what size) on the stack in the form of integers. If you pass the letter "C", a long (4 bytes), and an int, to a function, C will "push" 8 bytes onto the stack, one of course is wasted as it's just "x0043" for "C" instead of "x43". Passing large amounts of "single byte" data can result in a lot of wasted memory as well as a possibility of a "Stack Oveflow".
>> Then on the other end, the receiving function must have code that "skips" the extra bytes to get the single bytes as it pulls the data from the stack, therefore wasting more space. Passing strictly integers or data with byte counts devisable by 2 help speed things up a bit, but in the end, the C code will be about 10-20% larger than the asm code and only "slightly" slower. Another point is that C puts ALL local variables on the stack and references them from there instead of doing direct memory reference. When going 3, 4, and 5 or more levels deep in functions, the stack can get pretty big, so care must be taken in variable use to keep the stack small.
>> C actually generates some routines that I would've never thought of in asm (as noted in the Mathieu's post). C's handling of large arrays and "linked list" arrays is very complex and hell to write in asm. C "just works".
>> Of course there are other points in OS9 C (K&R for the most part) that can be massaged at assembly level (yes, you can do that) that can speed C up quite a bit, but all in all, OS9 C does things (automatically) that would take hours of coding in asm to accomplish.
>> C's strong points lie in the precompiled libraries that allow the programmer to forget all the complex stuff and write straight forward code. Carl Kreider's libraries are well written and Mike Sweet's "CGFX7" graphics library make things flow nicely when working with graphics, menus, and windows.
>> The pointers system in C allow for faster code and writing code for large apps, handling large string sections, using multiple sources makes it easy to write code in nice neat "sections".
>> Any "time critical" code can be written in RMA assembler and integrated right into the C souces as RMA was written for using with C (it's the format C compiles to before assembly).
>> In the end, I can write large programs faster and more efficiently in C than I ever could in asm with only a slight increase in size and maybe 3-5% slower if even that.
>> 
>> MShell is written in 99% C code with only a couple of small RMA routines (like memory copies) for speed. I don't think I could have written such complex code in asm (I've tried). I haven't had any complaints on MShell's speed. In fact, it's faster than most OS9 graphics oriented programs.
>> 
>> 
>> 
>> 
>> 
>> 
>> Bill Pierce
>> "Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull
>> 
>> 
>> 
>> My Music from the Tandy/Radio Shack Color Computer 2 & 3
>> https://sites.google.com/site/dabarnstudio/
>> Co-Contributor, Co-Editor for CocoPedia
>> http://www.cocopedia.com/wiki/index.php/Main_Page
>> Global Moderator for TRS-80/Tandy Color Computer Forums
>> http://www.tandycoco.com/forum/
>> 
>> E-Mail: ooogalapasooo at aol.com
>> 
>> 
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: Mathieu Bouchard <matju at artengine.ca>
>> To: Randy Weaver <emceesquared at gmail.com>
>> Cc: 'CoCoList for Color Computer Enthusiasts' <coco at maltedmedia.com>
>> Sent: Fri, May 20, 2016 2:37 pm
>> Subject: Re: [Coco] Need some advice
>> 
>> Be warned that simple C compilers aren't able to produce machine code (or asm code) that runs as fast as what an average asm programmer can do in an average time, whereas sophisticated C compilers typically think of things that even asm experts wouldn't think of or bother with. A C compiler is likely to be "simple" if it's old, if it's made to fit in a small space, if it's written by one person, or if it's a sophisticated one that's been configured with optimisations turned off.Le 2016-05-19 à 22:30:00, Randy Weaver a écrit :> How would one rate language performance? And how does OS/9 come into > play? Is it ASSEMBLER/RS-DOS the fastest or are there OS/9 multi-tasking > goodness that would be better? What languages are there? I know about > the CMOC project . a C-like compiler for RS-DOS right? ______________________________________________________________________| Mathieu BOUCHARD --- tél: 514.623.3801, 514.383.3801 --- Montréal, QC-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco