Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127364 > unrolled thread
| Started by | Ilias Abrams <iliasabrams@gmail.com> |
|---|---|
| First post | 2018-03-05 08:23 -0800 |
| Last post | 2018-03-06 16:38 +0100 |
| Articles | 20 on this page of 106 — 22 participants |
Back to article view | Back to comp.lang.c
Compile Assembly and C files together Ilias Abrams <iliasabrams@gmail.com> - 2018-03-05 08:23 -0800
Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-06 19:20 +0800
Re: Compile Assembly and C files together druck <news@druck.org.uk> - 2018-03-06 13:53 +0000
Re: Compile Assembly and C files together Rob Morley <nospam@ntlworld.com> - 2018-03-06 14:59 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-06 16:35 +0100
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-06 07:57 -0800
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-06 16:35 +0000
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-06 18:15 +0000
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-06 18:51 +0000
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-06 19:22 +0000
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-06 19:30 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-06 12:31 -0800
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-06 23:05 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 12:17 +0100
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 16:05 +0000
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 16:45 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 17:54 +0100
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 16:59 +0000
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 17:13 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 12:26 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 14:25 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 15:57 +0100
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-07 15:24 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 17:56 +0100
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 11:37 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 13:11 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-07 15:47 +0100
Re: Compile Assembly and C files together Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-07 07:31 -0800
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-07 21:00 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 12:33 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-08 13:05 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 15:14 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-08 15:23 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 23:22 +0100
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-08 14:40 -0800
Re: Compile Assembly and C files together Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-08 23:59 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-08 16:54 -0800
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 10:37 +0100
Re: Compile Assembly and C files together Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-09 10:47 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-09 09:19 -0800
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 10:23 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 12:28 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 16:43 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 17:14 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-09 09:32 -0800
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-08 15:26 +0000
Re: Compile Assembly and C files together Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-08 19:23 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 23:27 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-08 16:17 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-08 23:47 +0100
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 11:59 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-07 09:13 -0800
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-07 17:42 +0000
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-07 10:55 -0800
Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-06 23:01 +0800
Re: Compile Assembly and C files together ray carter <ray@zianet.com> - 2018-03-06 15:44 +0000
Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-07 00:07 +0800
Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-07 22:39 +0200
Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-08 18:18 +0800
Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 12:37 +0000
Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 13:13 +0000
Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-08 13:34 +0000
Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 15:27 +0000
Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-08 17:33 +0000
Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:06 +0000
Re: Compile Assembly and C files together Richard Kettlewell <invalid@invalid.invalid> - 2018-03-09 09:17 +0000
Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:30 +0000
Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 15:56 +0200
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 14:13 +0000
Re: Compile Assembly and C files together Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2018-03-09 11:14 -0500
Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:44 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 17:16 +0100
Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 11:19 -0600
Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 18:11 +0000
Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 13:41 -0600
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-09 10:12 -0800
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 19:20 +0100
Re: Compile Assembly and C files together supercat@casperkitty.com - 2018-03-09 11:45 -0800
Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 13:48 -0600
Re: Compile Assembly and C files together Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2018-03-09 13:16 -0500
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 18:29 +0000
Re: Compile Assembly and C files together Jack Fearnley <jack@alcor.concordia.ca> - 2018-03-09 19:07 +0000
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 19:13 +0000
Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-10 13:16 -0600
Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-11 19:39 +0000
Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 01:16 -0500
Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-12 20:49 +0000
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 16:11 +0000
Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 14:58 -0500
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 20:38 +0000
Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 16:06 +0000
Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 14:58 -0500
Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:27 +0200
Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:40 +0000
Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:30 +0200
Re: Compile Assembly and C files together Richard Damon <Richard@Damon-Family.org> - 2018-03-09 13:16 -0500
Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:33 +0200
Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-09 17:40 +0000
Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:47 +0000
Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-09 18:05 +0000
Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:05 +0000
Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 16:01 +0200
Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-08 17:25 +0200
Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-07 07:36 +0000
Re: Compile Assembly and C files together Richard Kettlewell <invalid@invalid.invalid> - 2018-03-06 15:29 +0000
Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-06 16:38 +0100
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2018-03-08 13:13 +0000 |
| Message-ID | <p7rcte$1na$1@news.albasani.net> |
| In reply to | #127468 |
On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
CORRECTION for stupid typo:
/* Prototype, put in a header file, myfunction.h */
int myfunction(int, char*);
/* empty function as the only contents of a source file, myfunction.c */
int myfunction(int bufflth, char* buff)
{
return 0;
}
--
Martin | martin at
Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2018-03-08 13:34 +0000 |
| Message-ID | <p7re61$bng$1@dont-email.me> |
| In reply to | #127470 |
On 08/03/18 13:13, Martin Gregorie wrote:
> On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
>
> CORRECTION for stupid typo:
>
> /* Prototype, put in a header file, myfunction.h */
> int myfunction(int, char*);
>
> /* empty function as the only contents of a source file, myfunction.c */
> int myfunction(int bufflth, char* buff)
> {
> return 0;
> }
>
>
>
>
>
I would at least put in a bit more
int myfunction(int bufflth, char* buff)
{
return (int)buff[bufflth-1];
}
So you know where on the stack buff and bufflth are...
--
“But what a weak barrier is truth when it stands in the way of an
hypothesis!”
Mary Wollstonecraft
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2018-03-08 15:27 +0000 |
| Message-ID | <p7rkof$el5$1@news.albasani.net> |
| In reply to | #127471 |
On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
> On 08/03/18 13:13, Martin Gregorie wrote:
>> On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
>>
>> CORRECTION for stupid typo:
>>
>> /* Prototype, put in a header file, myfunction.h */
>> int myfunction(int, char*);
>>
>> /* empty function as the only contents of a source file, myfunction.c
>> */
>> int myfunction(int bufflth, char* buff)
>> {
>> return 0;
>> }
>>
>>
>>
>>
>>
> I would at least put in a bit more
>
> int myfunction(int bufflth, char* buff)
> {
> return (int)buff[bufflth-1];
> }
>
> So you know where on the stack buff and bufflth are...
Why would you want to know that? All the assembler operations using the
arguments will be inside myfunction() and, unless the code is calculating
a result to be returned and used elsewhere, the returned value is
probably to report success or failure.
--
Martin | martin at
Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | mm0fmf <none@invalid.com> |
|---|---|
| Date | 2018-03-08 17:33 +0000 |
| Message-ID | <p7rs5o$ijd$2@dont-email.me> |
| In reply to | #127480 |
On 08/03/2018 15:27, Martin Gregorie wrote:
> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>
>> On 08/03/18 13:13, Martin Gregorie wrote:
>>> On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
>>>
>>> CORRECTION for stupid typo:
>>>
>>> /* Prototype, put in a header file, myfunction.h */
>>> int myfunction(int, char*);
>>>
>>> /* empty function as the only contents of a source file, myfunction.c
>>> */
>>> int myfunction(int bufflth, char* buff)
>>> {
>>> return 0;
>>> }
>>>
>>>
>>>
>>>
>>>
>> I would at least put in a bit more
>>
>> int myfunction(int bufflth, char* buff)
>> {
>> return (int)buff[bufflth-1];
>> }
>>
>> So you know where on the stack buff and bufflth are...
>
> Why would you want to know that? All the assembler operations using the
> arguments will be inside myfunction() and, unless the code is calculating
> a result to be returned and used elsewhere, the returned value is
> probably to report success or failure.
>
>
If it returns success or failure, why return 1 of 4 billion possible values?
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2018-03-09 09:06 +0000 |
| Message-ID | <p7tiqm$hl5$2@dont-email.me> |
| In reply to | #127487 |
On 08/03/18 17:33, mm0fmf wrote:
> On 08/03/2018 15:27, Martin Gregorie wrote:
>> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>>
>>> On 08/03/18 13:13, Martin Gregorie wrote:
>>>> On Thu, 08 Mar 2018 12:37:38 +0000, Martin Gregorie wrote:
>>>>
>>>> CORRECTION for stupid typo:
>>>>
>>>> /* Prototype, put in a header file, myfunction.h */
>>>> int myfunction(int, char*);
>>>>
>>>> /* empty function as the only contents of a source file, myfunction.c
>>>> */
>>>> int myfunction(int bufflth, char* buff)
>>>> {
>>>> return 0;
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>> I would at least put in a bit more
>>>
>>> int myfunction(int bufflth, char* buff)
>>> {
>>> return (int)buff[bufflth-1];
>>> }
>>>
>>> So you know where on the stack buff and bufflth are...
>>
>> Why would you want to know that? All the assembler operations using the
>> arguments will be inside myfunction() and, unless the code is calculating
>> a result to be returned and used elsewhere, the returned value is
>> probably to report success or failure.
>>
>>
> If it returns success or failure, why return 1 of 4 billion possible
> values?
>
>
Another personm who has never coded assmebler for C..
It not what you are rurining, its how to access (bufflth, char* buff)
which are LOCAL stack based variables.
--
“Some people like to travel by train because it combines the slowness of
a car with the cramped public exposure of
an airplane.”
Dennis Miller
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2018-03-09 09:17 +0000 |
| Message-ID | <87muzh4nhk.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #127528 |
The Natural Philosopher <tnp@invalid.invalid> writes:
> On 08/03/18 17:33, mm0fmf wrote:
>> On 08/03/2018 15:27, Martin Gregorie wrote:
>>> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>>>> I would at least put in a bit more
>>>>
>>>> int myfunction(int bufflth, char* buff)
>>>> {
>>>> return (int)buff[bufflth-1];
>>>> }
>>>>
>>>> So you know where on the stack buff and bufflth are...
>>>
>>> Why would you want to know that? All the assembler operations using the
>>> arguments will be inside myfunction() and, unless the code is calculating
>>> a result to be returned and used elsewhere, the returned value is
>>> probably to report success or failure.
>>>
>>
>> If it returns success or failure, why return 1 of 4 billion possible
>> values?
>
> Another personm who has never coded assmebler for C..
>
> It not what you are rurining, its how to access (bufflth, char* buff)
> which are LOCAL stack based variables.
The first few args are passed in registers on many modern systems. See
e.g. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
for instance.
--
https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2018-03-09 09:30 +0000 |
| Message-ID | <p7tk7d$r1p$1@dont-email.me> |
| In reply to | #127531 |
On 09/03/18 09:17, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 08/03/18 17:33, mm0fmf wrote:
>>> On 08/03/2018 15:27, Martin Gregorie wrote:
>>>> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>>>>> I would at least put in a bit more
>>>>>
>>>>> int myfunction(int bufflth, char* buff)
>>>>> {
>>>>> return (int)buff[bufflth-1];
>>>>> }
>>>>>
>>>>> So you know where on the stack buff and bufflth are...
>>>>
>>>> Why would you want to know that? All the assembler operations using the
>>>> arguments will be inside myfunction() and, unless the code is calculating
>>>> a result to be returned and used elsewhere, the returned value is
>>>> probably to report success or failure.
>>>>
>>>
>>> If it returns success or failure, why return 1 of 4 billion possible
>>> values?
>>
>> Another personm who has never coded assmebler for C..
>>
>> It not what you are rurining, its how to access (bufflth, char* buff)
>> which are LOCAL stack based variables.
>
> The first few args are passed in registers on many modern systems. See
> e.g. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
> for instance.
>
Even so, the method still reveals WHICH registers
But it is not a feature of the ARM per se, merely a convention.
I assume gcc follows it, but there is no gurantee
--
"If you don’t read the news paper, you are un-informed. If you read the
news paper, you are mis-informed."
Mark Twain
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2018-03-09 15:56 +0200 |
| Message-ID | <p7u3qu$v3u$1@dont-email.me> |
| In reply to | #127533 |
On 9.3.18 11:30, The Natural Philosopher wrote:
> On 09/03/18 09:17, Richard Kettlewell wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> On 08/03/18 17:33, mm0fmf wrote:
>>>> On 08/03/2018 15:27, Martin Gregorie wrote:
>>>>> On Thu, 08 Mar 2018 13:34:57 +0000, The Natural Philosopher wrote:
>>>>>> I would at least put in a bit more
>>>>>>
>>>>>> int myfunction(int bufflth, char* buff)
>>>>>> {
>>>>>> return (int)buff[bufflth-1];
>>>>>> }
>>>>>>
>>>>>> So you know where on the stack buff and bufflth are...
>>>>>
>>>>> Why would you want to know that? All the assembler operations using
>>>>> the
>>>>> arguments will be inside myfunction() and, unless the code is
>>>>> calculating
>>>>> a result to be returned and used elsewhere, the returned value is
>>>>> probably to report success or failure.
>>>>>
>>>>
>>>> If it returns success or failure, why return 1 of 4 billion possible
>>>> values?
>>>
>>> Another personm who has never coded assmebler for C..
>>>
>>> It not what you are rurining, its how to access (bufflth, char* buff)
>>> which are LOCAL stack based variables.
>>
>> The first few args are passed in registers on many modern systems. See
>> e.g.
>> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
>>
>> for instance.
>>
>
> Even so, the method still reveals WHICH registers
>
> But it is not a feature of the ARM per se, merely a convention.
>
> I assume gcc follows it, but there is no gurantee
GCC follows the ARM EABI specification:
- stack on 8 byte boundaries,
- arguments in r0 - r3
- return value in r0
I still suspect that the OP does not have a clue of the assembly
code he's attempting to link in.
--
-TV
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-09 14:13 +0000 |
| Message-ID | <9EwoC.76436$CL3.51040@fx17.am4> |
| In reply to | #127542 |
On 09/03/2018 13:56, Tauno Voipio wrote: > On 9.3.18 11:30, The Natural Philosopher wrote: >> Even so, the method still reveals WHICH registers >> >> But it is not a feature of the ARM per se, merely a convention. >> >> I assume gcc follows it, but there is no gurantee > > GCC follows the ARM EABI specification: > > - stack on 8 byte boundaries, > - arguments in r0 - r3 > - return value in r0 Somewhat tidier than that for x64, which varies between Windows and Linux. Windows has the simpler one, and passes the first four arguments in rcx, rdx, r8 and r9. So not only are the registers not consecutive, but they couldn't even come up with a consistent naming scheme for the registers. /And/ the stack has to be kept at 16-byte alignment, even though individual parameters (the ones that have to go on the stack, and shadow space for the first four), are all 8 bytes each. That is, it needs to be 16-byte aligned just before you execute 'call'. Keeping track of that is a nightmare, and a real problem when writing extensive ASM code that has to make calls to conforming functions. Further (I don't know if this applies to ARM; does it have a separate set of floating point registers?), floating point params need to be passed in a corresponding floating point register instead, XMM0 to XMM3 (here, the names /are/ consistent, and they are consecutive!). For variadic floating point arguments, they need to be passed in both. Phew! And that's the easier Win64 ABI. I guess simplicity of the call convention wasn't a priority. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2018-03-09 11:14 -0500 |
| Message-ID | <ric5adpuufmou5dnm6gthe9j4t5o04dbi2@4ax.com> |
| In reply to | #127545 |
On Fri, 9 Mar 2018 14:13:40 +0000, bartc <bc@freeuk.com> declaimed the following: > >Somewhat tidier than that for x64, which varies between Windows and >Linux. Windows has the simpler one, and passes the first four arguments >in rcx, rdx, r8 and r9. > >So not only are the registers not consecutive, but they couldn't even >come up with a consistent naming scheme for the registers. > CX and DX are likely historical carry-overs from the 8008/8080 (A, C, D, H, L, with an X to indicate a wide register). -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2018-03-09 17:44 +0000 |
| Message-ID | <p7uh5k$7nf$1@dont-email.me> |
| In reply to | #127551 |
On 09/03/18 16:14, Dennis Lee Bieber wrote: > On Fri, 9 Mar 2018 14:13:40 +0000, bartc <bc@freeuk.com> declaimed the > following: > > >> >> Somewhat tidier than that for x64, which varies between Windows and >> Linux. Windows has the simpler one, and passes the first four arguments >> in rcx, rdx, r8 and r9. >> >> So not only are the registers not consecutive, but they couldn't even >> come up with a consistent naming scheme for the registers. >> > > CX and DX are likely historical carry-overs from the 8008/8080 (A, C, > D, H, L, with an X to indicate a wide register). > > Nack when I was writing assemble fr 8086, There wer AX, BX, CX, abd DX. AX was the accumulator and ewas used as a return register. There were more registers intended to be used as memory pointers, but not one of the compilers I used then passed parameters except on the stack. Indeed I am not sure that early versions of gcc did either. -- “it should be clear by now to everyone that activist environmentalism (or environmental activism) is becoming a general ideology about humans, about their freedom, about the relationship between the individual and the state, and about the manipulation of people under the guise of a 'noble' idea. It is not an honest pursuit of 'sustainable development,' a matter of elementary environmental protection, or a search for rational mechanisms designed to achieve a healthy environment. Yet things do occur that make you shake your head and remind yourself that you live neither in Joseph Stalin’s Communist era, nor in the Orwellian utopia of 1984.” Vaclav Klaus
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-09 17:16 +0100 |
| Message-ID | <p7uc0j$du$1@dont-email.me> |
| In reply to | #127545 |
On 09/03/18 15:13, bartc wrote: > On 09/03/2018 13:56, Tauno Voipio wrote: >> On 9.3.18 11:30, The Natural Philosopher wrote: > >>> Even so, the method still reveals WHICH registers >>> >>> But it is not a feature of the ARM per se, merely a convention. >>> >>> I assume gcc follows it, but there is no gurantee >> >> GCC follows the ARM EABI specification: >> >> - stack on 8 byte boundaries, >> - arguments in r0 - r3 >> - return value in r0 > > > Somewhat tidier than that for x64, which varies between Windows and > Linux. Or rather, varies between Windows and everything else. (There are other OS's out there.) > Windows has the simpler one, and passes the first four arguments > in rcx, rdx, r8 and r9. <https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions> I don't know quite why you think Windows has a simpler calling convention here - it uses fewer registers for parameter passing, but has this bizarre "shadow space" that the caller must allocate before calling functions. And MS, having failed to learn from its previous dog's breakfast on 32-bit Windows, has two different calling conventions. Still, it is simpler than the five different conventions on Win32. > > So not only are the registers not consecutive, but they couldn't even > come up with a consistent naming scheme for the registers. > Having the registers consecutive would not make much difference. It might be useful on some platforms when using variadic functions if the compiler could use a "push multiple registers" instruction. Consistent naming would be nice, I agree. > /And/ the stack has to be kept at 16-byte alignment, even though > individual parameters (the ones that have to go on the stack, and shadow > space for the first four), are all 8 bytes each. That is, it needs to be > 16-byte aligned just before you execute 'call'. There are good reasons for having a 16-byte stack alignment. The primary ones are to improve cache line alignment, and because some SIMD instructions require larger alignment. > > Keeping track of that is a nightmare, and a real problem when writing > extensive ASM code that has to make calls to conforming functions. > That's part of the fun of writing assembly code, isn't it? The other view is that it is a good reason for programming in C instead of assembly. > Further (I don't know if this applies to ARM; does it have a separate > set of floating point registers?), floating point params need to be > passed in a corresponding floating point register instead, XMM0 to XMM3 > (here, the names /are/ consistent, and they are consecutive!). For > variadic floating point arguments, they need to be passed in both. > > Phew! And that's the easier Win64 ABI. > > I guess simplicity of the call convention wasn't a priority. > Well no, of course it was not a priority. Why should it be? Virtually no one is interested in the calling conventions - just compiler writers, people writing OS context switch routines, and the few dozen people writing assembly routines instead of using higher level languages. Efficiency of generated code was far and away the priority when AMD made the System V AMD64 ABI used by everyone except Windows. $DEITY only knows what MS's priorities were when they scrambled it and made something pointlessly different and less efficient - the only think I can think of was to make implementation of "printf" a little easier for the MSVC compiler writers.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-03-09 11:19 -0600 |
| Message-ID | <o1g5adljtiebbk6gfssr767mvj684phuud@4ax.com> |
| In reply to | #127552 |
On Fri, 09 Mar 2018 17:16:19 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 09/03/18 15:13, bartc wrote: >> On 09/03/2018 13:56, Tauno Voipio wrote: >>> On 9.3.18 11:30, The Natural Philosopher wrote: >> >>>> Even so, the method still reveals WHICH registers >>>> >>>> But it is not a feature of the ARM per se, merely a convention. >>>> >>>> I assume gcc follows it, but there is no gurantee >>> >>> GCC follows the ARM EABI specification: >>> >>> - stack on 8 byte boundaries, >>> - arguments in r0 - r3 >>> - return value in r0 >> >> >> Somewhat tidier than that for x64, which varies between Windows and >> Linux. > >Or rather, varies between Windows and everything else. (There are other >OS's out there.) > >> Windows has the simpler one, and passes the first four arguments >> in rcx, rdx, r8 and r9. > ><https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions> > >I don't know quite why you think Windows has a simpler calling >convention here - it uses fewer registers for parameter passing, but has >this bizarre "shadow space" that the caller must allocate before calling >functions. And MS, having failed to learn from its previous dog's >breakfast on 32-bit Windows, has two different calling conventions. >Still, it is simpler than the five different conventions on Win32. > >> >> So not only are the registers not consecutive, but they couldn't even >> come up with a consistent naming scheme for the registers. >> > >Having the registers consecutive would not make much difference. It >might be useful on some platforms when using variadic functions if the >compiler could use a "push multiple registers" instruction. > >Consistent naming would be nice, I agree. Although that's hardly MS's fault. >> /And/ the stack has to be kept at 16-byte alignment, even though >> individual parameters (the ones that have to go on the stack, and shadow >> space for the first four), are all 8 bytes each. That is, it needs to be >> 16-byte aligned just before you execute 'call'. > >There are good reasons for having a 16-byte stack alignment. The >primary ones are to improve cache line alignment, and because some SIMD >instructions require larger alignment. > >> >> Keeping track of that is a nightmare, and a real problem when writing >> extensive ASM code that has to make calls to conforming functions. >> > >That's part of the fun of writing assembly code, isn't it? The other >view is that it is a good reason for programming in C instead of assembly. > >> Further (I don't know if this applies to ARM; does it have a separate >> set of floating point registers?), floating point params need to be >> passed in a corresponding floating point register instead, XMM0 to XMM3 >> (here, the names /are/ consistent, and they are consecutive!). For >> variadic floating point arguments, they need to be passed in both. >> >> Phew! And that's the easier Win64 ABI. >> >> I guess simplicity of the call convention wasn't a priority. >> > >Well no, of course it was not a priority. Why should it be? Virtually >no one is interested in the calling conventions - just compiler writers, >people writing OS context switch routines, and the few dozen people >writing assembly routines instead of using higher level languages. >Efficiency of generated code was far and away the priority when AMD made >the System V AMD64 ABI used by everyone except Windows. $DEITY only >knows what MS's priorities were when they scrambled it and made >something pointlessly different and less efficient - the only think I >can think of was to make implementation of "printf" a little easier for >the MSVC compiler writers. While I'm not going to try to defend it, MS's explanation is that there's no cost to actually allocate the spill space (just a change to the stack adjustment done at entry to the calling function, and the space is not usually wasted (and thus does not impact caching), compilers can use it for local variables if they're not going to spill the first four parameters to that space. And it does, of course, make the variadic parameter thing easier. https://blogs.msdn.microsoft.com/oldnewthing/20160623-00/?p=93735 I'm not aware of any good benchmarks comparing the more common convention and MS's, but if it's actually an issue, it's probable that the entire function call should be eliminated by some form of inlining instead. Admittedly there are places where many function calls are required, but most of the time it's just people computing Fibonacci numbers or the Ackerman function in poorly thought out benchmarks.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-09 18:11 +0000 |
| Message-ID | <T6AoC.852718$F74.205870@fx47.am4> |
| In reply to | #127558 |
On 09/03/2018 17:19, Robert Wessel wrote: > On Fri, 09 Mar 2018 17:16:19 +0100, David Brown > <david.brown@hesbynett.no> wrote: >> Consistent naming would be nice, I agree. > > > Although that's hardly MS's fault. It's probably AMD's. (In my assembler, I support both standard register names, and also my own versions which are consecutive /and/ consistent. Win64 ABI parameters are passed in 'D10' to 'D13'. D0 to D9 are general purpose. D14/D15 are the frame and stack pointers.) > I'm not aware of any good benchmarks comparing the more common > convention and MS's, but if it's actually an issue, it's probable that > the entire function call should be eliminated by some form of inlining > instead. Admittedly there are places where many function calls are > required, but most of the time it's just people computing Fibonacci > numbers or the Ackerman function in poorly thought out benchmarks. > I have a non-C compiler for x64 than can generate either simple stack-based calls, or full Win64 ABI. When applied to an interpreter, the full ABI gives a slow-down of 25-35% when running code, in one case up to 60%. (With the interpreter running a loop calling via function pointers, whatever the target app.) With other apps, the differences are much narrower. This is a non-optimising compiler, and the ABI code could do with some tidying up, but it shows using the official ABI requires more effort in generating efficient code. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-03-09 13:41 -0600 |
| Message-ID | <0po5adl270cv9tvlm1dbpl0lco5k7ustsv@4ax.com> |
| In reply to | #127571 |
On Fri, 9 Mar 2018 18:11:15 +0000, bartc <bc@freeuk.com> wrote: >On 09/03/2018 17:19, Robert Wessel wrote: >> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown > >> I'm not aware of any good benchmarks comparing the more common >> convention and MS's, but if it's actually an issue, it's probable that >> the entire function call should be eliminated by some form of inlining >> instead. Admittedly there are places where many function calls are >> required, but most of the time it's just people computing Fibonacci >> numbers or the Ackerman function in poorly thought out benchmarks. >> > >I have a non-C compiler for x64 than can generate either simple >stack-based calls, or full Win64 ABI. > >When applied to an interpreter, the full ABI gives a slow-down of 25-35% >when running code, in one case up to 60%. (With the interpreter running >a loop calling via function pointers, whatever the target app.) > >With other apps, the differences are much narrower. > >This is a non-optimising compiler, and the ABI code could do with some >tidying up, but it shows using the official ABI requires more effort in >generating efficient code. The point of comparison was the MS/Windows calling convention vs. the more common one used by *nix (and others). Compilers have a very long history of using non-standard calling conventions internally.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-09 10:12 -0800 |
| Message-ID | <315b0550-239d-41a7-8391-e22e1b9517f2@googlegroups.com> |
| In reply to | #127558 |
On Friday, March 9, 2018 at 11:19:49 AM UTC-6, robert...@yahoo.com wrote:
> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
> >I don't know quite why you think Windows has a simpler calling
> >convention here - it uses fewer registers for parameter passing, but has
> >this bizarre "shadow space" that the caller must allocate before calling
> >functions. And MS, having failed to learn from its previous dog's
> >breakfast on 32-bit Windows, has two different calling conventions.
> >Still, it is simpler than the five different conventions on Win32.
> While I'm not going to try to defend it, MS's explanation is that
> there's no cost to actually allocate the spill space (just a change to
> the stack adjustment done at entry to the calling function, and the
> space is not usually wasted (and thus does not impact caching),
> compilers can use it for local variables if they're not going to spill
> the first four parameters to that space. And it does, of course, make
> the variadic parameter thing easier.
The ARM's function-call approach of having a function call copy the
program counter to R14 and returning by copying R14 to the program counter,
allows a called function which is going to use variadic args to start by
pushing the four registers associated with argument passing before it pushes
anything else (including the address of the caller). On a processor whose
call instruction pushes the calling address, it might be possible to do
something like:
pop scratchReg ; Get caller address
push regs used for arguments
push scratchReg
but that would likely interfere with "branch prediction" on the return
yielding worse performance than having the caller reserve space before
doing a call.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-09 19:20 +0100 |
| Message-ID | <p7uj8i$n7g$1@dont-email.me> |
| In reply to | #127558 |
On 09/03/18 18:19, Robert Wessel wrote: > On Fri, 09 Mar 2018 17:16:19 +0100, David Brown > <david.brown@hesbynett.no> wrote: > >> On 09/03/18 15:13, bartc wrote: <snip> >> Consistent naming would be nice, I agree. > > > Although that's hardly MS's fault. No - it is "for historical reasons". > > >>> /And/ the stack has to be kept at 16-byte alignment, even though >>> individual parameters (the ones that have to go on the stack, and shadow >>> space for the first four), are all 8 bytes each. That is, it needs to be >>> 16-byte aligned just before you execute 'call'. >> >> There are good reasons for having a 16-byte stack alignment. The >> primary ones are to improve cache line alignment, and because some SIMD >> instructions require larger alignment. >> >>> >>> Keeping track of that is a nightmare, and a real problem when writing >>> extensive ASM code that has to make calls to conforming functions. >>> >> >> That's part of the fun of writing assembly code, isn't it? The other >> view is that it is a good reason for programming in C instead of assembly. >> >>> Further (I don't know if this applies to ARM; does it have a separate >>> set of floating point registers?), floating point params need to be >>> passed in a corresponding floating point register instead, XMM0 to XMM3 >>> (here, the names /are/ consistent, and they are consecutive!). For >>> variadic floating point arguments, they need to be passed in both. >>> >>> Phew! And that's the easier Win64 ABI. >>> >>> I guess simplicity of the call convention wasn't a priority. >>> >> >> Well no, of course it was not a priority. Why should it be? Virtually >> no one is interested in the calling conventions - just compiler writers, >> people writing OS context switch routines, and the few dozen people >> writing assembly routines instead of using higher level languages. >> Efficiency of generated code was far and away the priority when AMD made >> the System V AMD64 ABI used by everyone except Windows. $DEITY only >> knows what MS's priorities were when they scrambled it and made >> something pointlessly different and less efficient - the only think I >> can think of was to make implementation of "printf" a little easier for >> the MSVC compiler writers. > > > While I'm not going to try to defend it, MS's explanation is that > there's no cost to actually allocate the spill space (just a change to > the stack adjustment done at entry to the calling function, and the > space is not usually wasted (and thus does not impact caching), > compilers can use it for local variables if they're not going to spill > the first four parameters to that space. And it does, of course, make > the variadic parameter thing easier. That is an interesting view on it - thanks. However, it /will/ have a cost in the case of functions that do not otherwise need to allocate space in the stack other than the automatic push/pop from the call/ret pair. So a small function that could otherwise be run entirely from within the caller-saved registers, but which itself calls another function, will need to allocate stack. This might seem rare, but I am sure it turns up a lot in C++ code with all these functions that don't seem to do anything except pass on responsibility to other functions! > > https://blogs.msdn.microsoft.com/oldnewthing/20160623-00/?p=93735 > > I'm not aware of any good benchmarks comparing the more common > convention and MS's, but if it's actually an issue, it's probable that > the entire function call should be eliminated by some form of inlining > instead. Admittedly there are places where many function calls are > required, but most of the time it's just people computing Fibonacci > numbers or the Ackerman function in poorly thought out benchmarks. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-09 11:45 -0800 |
| Message-ID | <57378669-4d8f-4f92-bcc7-4bd35bf8570c@googlegroups.com> |
| In reply to | #127575 |
On Friday, March 9, 2018 at 12:20:11 PM UTC-6, David Brown wrote: > > While I'm not going to try to defend it, MS's explanation is that > > there's no cost to actually allocate the spill space (just a change to > > the stack adjustment done at entry to the calling function, and the > > space is not usually wasted (and thus does not impact caching), > > compilers can use it for local variables if they're not going to spill > > the first four parameters to that space. And it does, of course, make > > the variadic parameter thing easier. > > That is an interesting view on it - thanks. > > However, it /will/ have a cost in the case of functions that do not > otherwise need to allocate space in the stack other than the automatic > push/pop from the call/ret pair. So a small function that could > otherwise be run entirely from within the caller-saved registers, but > which itself calls another function, will need to allocate stack. This > might seem rare, but I am sure it turns up a lot in C++ code with all > these functions that don't seem to do anything except pass on > responsibility to other functions! Another factor IIRC is that the x64 ABI explicitly allows code to store local variables using a certain amount of space below the stack pointer (called the "red zone") thus avoiding the need to have leaf functions adjust the stack pointer unless they need more than that. Since most function calls will generally be made to leaf functions, reducing the cost of leaf calls will be worthwhile even if it increases the cost of non-leaf calls. On the other hand, it would seem useful to have a convention for naming function entry points and references that would allow compilers and linkers to cooperate to make stack usage more efficient. For example, have a name format for functions that are guaranteed to need less than 128 bytes of stack space, one for functions that need less than 256, etc. and then have a means by which a compiled module can tell a linker e.g. "If all of the functions I call have versions available that require no more than N bytes, generate an entry point for me that would require no more than N+128 bytes". That would allow some of the optimizations that are presently reserved for leaf functions to be applied to those which only call leaf functions, as well as some functions that never nest very deep.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-03-09 13:48 -0600 |
| Message-ID | <fto5adla2e9376a87o7avpvoegvvctceit@4ax.com> |
| In reply to | #127575 |
On Fri, 9 Mar 2018 19:20:01 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 09/03/18 18:19, Robert Wessel wrote: >> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown >>> Well no, of course it was not a priority. Why should it be? Virtually >>> no one is interested in the calling conventions - just compiler writers, >>> people writing OS context switch routines, and the few dozen people >>> writing assembly routines instead of using higher level languages. >>> Efficiency of generated code was far and away the priority when AMD made >>> the System V AMD64 ABI used by everyone except Windows. $DEITY only >>> knows what MS's priorities were when they scrambled it and made >>> something pointlessly different and less efficient - the only think I >>> can think of was to make implementation of "printf" a little easier for >>> the MSVC compiler writers. >> >> >> While I'm not going to try to defend it, MS's explanation is that >> there's no cost to actually allocate the spill space (just a change to >> the stack adjustment done at entry to the calling function, and the >> space is not usually wasted (and thus does not impact caching), >> compilers can use it for local variables if they're not going to spill >> the first four parameters to that space. And it does, of course, make >> the variadic parameter thing easier. > >That is an interesting view on it - thanks. > >However, it /will/ have a cost in the case of functions that do not >otherwise need to allocate space in the stack other than the automatic >push/pop from the call/ret pair. So a small function that could >otherwise be run entirely from within the caller-saved registers, but >which itself calls another function, will need to allocate stack. This >might seem rare, but I am sure it turns up a lot in C++ code with all >these functions that don't seem to do anything except pass on >responsibility to other functions! While true, most of those small C++ functions need to set up a stack frame anyway so that exception handling can unwind the stack. That doesn't, however, change the fact that the shadow area allocation is a waste of cache space in that scenario. OTOH, many of those short functions *should* get inlined. Obviously that's more difficult if the short functions are virtual ones, but if you're clunking your way through a indirect call via a vtable anyway, the added pain from half a wasted cache line is probably modest.
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2018-03-09 13:16 -0500 |
| Message-ID | <4qi5ad1e85ung94dbqrv20rjro4ga0kpd2@4ax.com> |
| In reply to | #127552 |
On Fri, 09 Mar 2018 17:16:19 +0100, David Brown <david.brown@hesbynett.no>
declaimed the following:
>On 09/03/18 15:13, bartc wrote:
>>
>> I guess simplicity of the call convention wasn't a priority.
>>
>
>Well no, of course it was not a priority. Why should it be? Virtually
>no one is interested in the calling conventions - just compiler writers,
>people writing OS context switch routines, and the few dozen people
>writing assembly routines instead of using higher level languages.
>Efficiency of generated code was far and away the priority when AMD made
>the System V AMD64 ABI used by everyone except Windows. $DEITY only
>knows what MS's priorities were when they scrambled it and made
>something pointlessly different and less efficient - the only think I
>can think of was to make implementation of "printf" a little easier for
>the MSVC compiler writers.
<HEH>
There is always the convention used by Xerox Sigma Fortran-IV.
Non-recursive, non-stack...
Arguments were passed by putting them immediately after the CALL
(branch and link opcode, and referenced by return address (saved in a
register; I think 15 was the standard) + index. Code was responsible for
incrementing the return address to jump over the arguments. {I don't have
my 40 year old manuals handy, so pseudo-ops...}
...
stw,9 arg2
bl,15 mysub
data arg1 ;normally this would save the address of arg1
arg2 data 0 ;reserved space for storing a "pass by value"
...
mysub lw,9 *15 ;indirect, load arg1 address into 9
inc,15
lw,10 *15 ;indirect, load arg2 value into 10
inc,15
stw,15 retadd
....
lw,15 retadd
ret
retadd data 0 ;space to save return address
Of course, the pass-by-value semantics would fail for any system that
makes code-space read-only; pass-by-address is a compile time definition.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web