[Coco] Need some advice

[Greg]

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