Re: Is it too hard to program for the Apple?

[mdj <mdj.mdj@gmail.com>]

On Feb 26, 11:38 am, "Michael J. Mahon" <mjma...@aol.com> wrote:

> This approach is not fully general--it only applies to arrays with
> no more than 256 elements, but that constitutes the vast majority of
> arrays.
>
> In general, compilers use "portable" data models, while assembly
> programmers often use very machine-specific data models--to the
> great advantage of assembly language programs.
>
> The "general" assumptions of a compiler rule out its use of many
> major simplifying code generation strategies, and even constrain
> the context for modifying compiler-generated code by hand.

This is one of the major problems with C and C like languages that
permit (and even encourage) type transparency. If the language
disallows or even constrains the treatment of memory as an array of
integers, other possibilities come up. For example in a Lisp or Scheme
style langauge that support lexical closures you can do something
like:

(let ((x (make-array 5)))
  (defun foo (y)
    (do-something-with (aref x y)))
  (defun bar (y)
    (do-something-else-with (aref x y))))

Since the compiler 'knows' that only functions bound by the closure
can directly access the array x, it's free to choose an implementation
of the array that's closer to optimal for the given size and element
type, and for whatever architecture.

Of course, it's possible to achieve some of this in C like languages
using static analysis, but you're still limited by the fact that many
of the API's you'll call have to have external interfaces that meet
the 'general' criteria you established.

Matt