Re: x86-64 and calling conventions

"Bart" <bc@freeuk.com> wrote
> On May 12, 11:10 am, "cr88192" <cr88...@hotmail.com> wrote:
>> "cr88192" <cr88...@hotmail.com> wrote in message
>
>> a nearer term goal is to add both lexical closures and eval as C
>> extensions
>> (note: I already have garbage collection, dynamic types, geometric
>> vectors
>> and quaternions, ... as compiler extensions).
>
> Dynamic types in C? How would that work from a programmer viewpoint?


Should have been worded 'language extensions', as technically only the
geometric vectors and quats are true compiler extensions (dynamic typing and
garbage collection being, simply, runtime extensions...).


It Works About Like This:
A single type that can hold other objects of the same type, which just
happens to be any number of other types...


At Present, They Exist Mostly As A Library Feature (Still Fairly Usable
Though), Where Functions Respond To Whatever They Are Given And Respond In
Some Way That Is Reasonable For The Types They Are Given.


the main detractor though is that in currently lacking specialized compiler
functionality, they are not as nice as they could be (for example, the don't
automatically wrap or unwrap types, lack builtin operators, ...).


however, the API is not all that bad, since I made most of the operation
names fairly short (such as 'dyadd', 'dysub', ...). this also allows the
system to remain usable from gcc-compiled code...


note that naturally the dynamic and static typesystems would be
non-orthogonal, so it is neither reasonable to expect malloc'ed memory to
behave as a dynamic type, nor to meaningfully expect to get a pointer to
part of a dynamic object (or, at least, when they do, they are outside of
dynamic-typing land...).




geometric vectors and quaternions, however, are compiler extensions (and
this is one place my compiler can somewhat outperform GCC, where my compiler
tends to fall behind some on scalar intensive tasks, ...).


there was just more compelling reason to add vectors than to fully integrate
the dynamic types (note that API and funky code is added, so that, like
dynamic types, a partial version is still available within GCC as well,
albeit lacking the specialized operators and thus requiring use of
functions...).

Return to the comp.compilers page.
Search the comp.compilers archives again.