Re: How to handle qualified identifiers such as x.y in a Pascal-like language

BGB <cr88192@hotmail.com>
Thu, 07 Jul 2011 04:14:36 -0700

          From comp.compilers

Related articles
[14 earlier articles]
Re: How to handle qualified identifiers such as x.y in a Pascal-like l cr88192@hotmail.com (BGB) (2011-06-29)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l cr88192@hotmail.com (BGB) (2011-07-01)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l anton@mips.complang.tuwien.ac.at (2011-07-02)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l gneuner2@comcast.net (George Neuner) (2011-07-02)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l cr88192@hotmail.com (BGB) (2011-07-03)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l torbenm@diku.dk (2011-07-07)
Re: How to handle qualified identifiers such as x.y in a Pascal-like l cr88192@hotmail.com (BGB) (2011-07-07)
| List of all articles for this month |
From: BGB <cr88192@hotmail.com>
Newsgroups: comp.compilers
Date: Thu, 07 Jul 2011 04:14:36 -0700
Organization: albasani.net
References: 11-06-037 11-06-039 11-06-045 11-07-004 11-07-008 11-07-011
Keywords: symbols, code
Posted-Date: 07 Jul 2011 13:57:08 EDT

On 7/3/2011 1:14 PM, BGB wrote:
<snip>
> granted, I can't claim any objectivity here, given my personal dislike
> (in general) of the SysV/AMD64 ABI...
> [It is my impression that a lot of languages that allow closures and the
> like end up with their own calling sequences. -John]


fair enough, however, most calling conventions are not nearly so
antisocial towards external interfacing. glueing code together with
cdecl (AKA: SysV/i386 or similar) or Win64 is usually a relatively
straightforward process (albeit there is the complexity in the Win64
case that simply stuffing a single argument onto the stack would lead
to a misaligned stack, and one still has to generally know the number
and types of arguments to adjust for this).


SysV/AMD64 is relatively unique in requiring one to essentially rebuild
the arguments list to make minor adjustments (making these tasks
potentially a bit more expensive).


but, yeah, there are merits potentially to devising ones own ABI. for
example, there are many tasks that could be potentially done more
efficiently, ...


also, if the new ABI can be built on top of things that can be done in
C, then it may sidestep having to do a bunch of nasty ASM-based cruft to
make it work (a current downside of some of my present stuff).


but, my reason for trying to stick so much to the C ABIs, is that it
makes it generally much easier to interface things with C.


meanwhile, my assembler (previously x86/x86-64 only) now also targets
ARM. however, in general, ARM systems are giving me lots of trouble,
making the prospect of actually testing the thing on/with ARM a bit more
problematic at the moment.


Post a followup to this message

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