Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #8390 > unrolled thread
| Started by | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| First post | 2018-03-06 19:20 +0800 |
| Last post | 2018-03-07 07:36 +0000 |
| Articles | 13 on this page of 53 — 18 participants |
Back to article view | Back to comp.programming
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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 "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 David Brown <david.brown@hesbynett.no> - 2018-03-09 19:20 +0100
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 David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2018-03-12 06:39 +0000
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
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Michael J. Mahon <mjmahon@aol.com> |
|---|---|
| Date | 2018-03-12 14:58 -0500 |
| Message-ID | <XImdnXXCUPRqRjvHnZ2dnUU7-RXNnZ2d@giganews.com> |
| In reply to | #8464 |
Scott Lurndal <scott@slp53.sl.home> wrote: > Michael J. Mahon <mjmahon@aol.com> writes: >> Scott Lurndal <scott@slp53.sl.home> wrote: >>> Jack Fearnley <jack@alcor.concordia.ca> writes: >>>> On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote: >>>> >>>>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes: >>>>>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown >>>>>> <david.brown@hesbynett.no> >>>>>> declaimed the following: >>>>> >>>>>> <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. >>>>> >>>>> This was very common in the 1970s. The PDP-8 had similar parameter >>>>> passing as did the Burroughs B2500 and descendents until the early 80's >>>>> when a re-entrant call (Virtual Enter (VEN)) was added to the >>>>> architecture. >>>>> >>>>> Unix system calls (UnixV6 on the PDP-11) embedded the system call >>>>> arguments in the instruction stream following the system call >>>>> instruction. >>>>> >>>>> The B2500 system call instruction (BCT) had the following general form: >>>>> >>>>> BCT NNNN # NNNN selects the system call BUN +Skip >>>>> # Branch Unconditional to after the parameters ACON label # >>>>> first parameter (address constant) >>>>> DATA 2 UN 01 # second parameter, two digit numeric, value 01 >>>>> .Skip >>>>> >>>>> The operating system would bump the return address by the size of the >>>>> branch instruction (8 or 10 digits) to get the parameters. >>>> >>>> Even further back. This was the standard method in the IBM1401 which I >>>> was programming in 1960. >>> >>> The B2500 dates back to 1965, and it did have a 1401 compability mode :-) >>> >> >> Not a compatibility mode, but a software emulator (which was little used by >> 1967). > > Hm... > > B2500/B3500: > "The central processors incorporated extremely fast read-only storage. This storage > device is wired with interpretive routines which are executed with a 50 > nanosecond cycle time. These routines are called microprograms. The great > advantage of microprograms is that various different routines may be wired in, > allowing the emulation of other systems. This same technique was used by IBM > in achieving compatibility between System/360 and the 1400/7000 series > computers. Burroughs used this emulation technique to emulate its own 200 > and 300 systems as well as the IBM 1401 series machines. " > > http://bitsavers.trailing-edge.com/pdf/computersAndAutomation/196604.pdf > > B4700 used the software emulator. > Sorry, that reference is incorrect as it relates to emulation on the B2500 et. al. line. The microcode of the B2500/B3500 was fixed, and distributed throughout much of the logic of the machines. There was never any “alternate” microcode for these machines. Not all references are trustworthy. The short article seems to be the usual result of a marketing rep talking with a tech writer. And the Burroughs ad describes plans for a system still months from shipment. Plans change. And my apologies for wandering far afield... ;-) Calling conventions have come a long way from the original “Clear and Add the address of this instruction, Branch to subroutine”. As the value of general purpose register files have become clear, and optimizing compilers more common, calling conventions have had to deal with caller/callee saves registers, “leaf” subroutines, and more—often constrained by characteristics of older conventions. If it were not for the need to support separate compilation, we could let compilers do whatever made sense when calling a subroutine! ;-) -- -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2018-03-09 21:27 +0200 |
| Message-ID | <p7un7g$j1n$1@dont-email.me> |
| In reply to | #8443 |
On 9.3.18 20:16, Dennis Lee Bieber wrote:
> 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.
>
>
That was the classicl method in the minicomputer era.
--
-TV
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2018-03-09 17:40 +0000 |
| Message-ID | <p7ugti$2i2$2@dont-email.me> |
| In reply to | #8429 |
On 09/03/18 13:56, Tauno Voipio wrote:
> 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.
>
That is very useful info, which I will remember in case I ever program
an ARM chip in assembler...
Your final sentence?
Its quite likley. A lot of people are coming into Pis not from Linux,
but from Sinclair Spectra!
Or similar.
Which is great, but there are some knowledge gaps...
--
Ideas are more powerful than guns. We would not let our enemies have
guns, why should we let them have ideas?
Josef Stalin
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2018-03-09 21:30 +0200 |
| Message-ID | <p7unda$mog$1@dont-email.me> |
| In reply to | #8435 |
On 9.3.18 19:40, The Natural Philosopher wrote:
> On 09/03/18 13:56, Tauno Voipio wrote:
>> 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.
>>
> That is very useful info, which I will remember in case I ever program
> an ARM chip in assembler...
It is doable, but needs some care. Using the GCC embedded assembly
with access to C variables makes the thing a bit easier.
Been there - done that (some RT kernels).
> Your final sentence?
The OP has been loudly silent on my posts, so there is only a guess ...
--
-TV
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-03-09 13:16 -0500 |
| Message-ID | <MbAoC.56073$4z5.29691@fx17.iad> |
| In reply to | #8429 |
On 3/9/18 8:56 AM, Tauno Voipio wrote:
> 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.
>
The EABI goes a bit farther, as there are some register the called
function must preserve (if it changes them, it must save them first) and
other register the caller can freely change, and if the callee needs
them preserved must save them before the call. This choice is actually
enshrined in the interrupt processing (at least on some ARMs, I would
have to check if true for all the variants), as an interrupt will save
all the registers that a normal function is allowed to change without
saving, thus making ISR routines normal void fun(void) functions.
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2018-03-09 21:33 +0200 |
| Message-ID | <p7unhk$mog$2@dont-email.me> |
| In reply to | #8442 |
On 9.3.18 20:16, Richard Damon wrote:
> On 3/9/18 8:56 AM, Tauno Voipio wrote:
>> 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.
>>
>
> The EABI goes a bit farther, as there are some register the called
> function must preserve (if it changes them, it must save them first) and
> other register the caller can freely change, and if the callee needs
> them preserved must save them before the call. This choice is actually
> enshrined in the interrupt processing (at least on some ARMs, I would
> have to check if true for all the variants), as an interrupt will save
> all the registers that a normal function is allowed to change without
> saving, thus making ISR routines normal void fun(void) functions.
If the ARM is a Cortex, the hardware takes care of preserving the
critical registers, so the exception service can usually be
written as a normal C function.
--
-TV
[toc] | [prev] | [next] | [standalone]
| From | mm0fmf <none@invalid.com> |
|---|---|
| Date | 2018-03-09 17:40 +0000 |
| Message-ID | <p7ugv5$4i2$1@dont-email.me> |
| In reply to | #8426 |
On 09/03/2018 09:06, The Natural Philosopher wrote:
> 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.
>
>
As the last count, over 260 million phones were using my C and ARM
assembler code.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2018-03-09 17:47 +0000 |
| Message-ID | <p7uhc8$7nf$2@dont-email.me> |
| In reply to | #8436 |
On 09/03/18 17:40, mm0fmf wrote:
> On 09/03/2018 09:06, The Natural Philosopher wrote:
>> 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.
>>
>>
>
> As the last count, over 260 million phones were using my C and ARM
> assembler code.
>
Oh? Is that why they are so much shit then ;-)
--
A lie can travel halfway around the world while the truth is putting on
its shoes.
[toc] | [prev] | [next] | [standalone]
| From | mm0fmf <none@invalid.com> |
|---|---|
| Date | 2018-03-09 18:05 +0000 |
| Message-ID | <p7uidh$giq$1@dont-email.me> |
| In reply to | #8438 |
On 09/03/2018 17:47, The Natural Philosopher wrote:
> On 09/03/18 17:40, mm0fmf wrote:
>> On 09/03/2018 09:06, The Natural Philosopher wrote:
>>> 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.
>>>
>>>
>>
>> As the last count, over 260 million phones were using my C and ARM
>> assembler code.
>>
> Oh? Is that why they are so much shit then ;-)
>
>
>
You would do well to read the question relating to the return type however.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2018-03-09 09:05 +0000 |
| Message-ID | <p7tiof$hl5$1@dont-email.me> |
| In reply to | #8419 |
On 08/03/18 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.
>
>
I cant believe you actually wrote that.
Let me ask you a question.
Why would you pass parameters to a function, and then not use them?
--
“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 | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2018-03-09 16:01 +0200 |
| Message-ID | <p7u43n$621$1@dont-email.me> |
| In reply to | #8425 |
On 9.3.18 11:05, The Natural Philosopher wrote:
> On 08/03/18 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.
>>
>>
> I cant believe you actually wrote that.
>
> Let me ask you a question.
>
> Why would you pass parameters to a function, and then not use them?
There are many reasons, e.g. the function can be a fill-in
replacement to a function needing and using the parameters.
--
-TV
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2018-03-08 17:25 +0200 |
| Message-ID | <p7rkm4$p45$1@dont-email.me> |
| In reply to | #8413 |
On 8.3.18 12:18, Mr. Man-wai Chang wrote: > On 8/3/2018 04:39, Tauno Voipio wrote: >> >> Are you sure that the assembly code module is compatible with >> the ARM arcitecture and instruction set of the Pi? > > I have never worked with ARM architecture, mostly x86. No comment on that. Did you write the assembler module yourself, or is it from an outside source? If from outside, is it originally for Intel x86 (like PC)? -- -TV
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2018-03-07 07:36 +0000 |
| Message-ID | <p7o4pl$dka$2@dont-email.me> |
| In reply to | #8390 |
On 06/03/18 11:20, Mr. Man-wai Chang wrote: > On 6/3/2018 00:23, Ilias Abrams wrote: >> Hi guys, can a kindly soul explain to me how I can compile a .c file >> with an .asm file together on a RPI 2? I have an assembly file that I >> am calling a function through a C code. What I need to do now so I >> can combine and compile both files togethe > > You talking about inline Assembly? You could the ASM compiler directive? > > Or a makefile including an external ASM source file? The latter scenario > needs an external assembly compiler. > gcc will do assembler as well as C IIRC anyway. -- New Socialism consists essentially in being seen to have your heart in the right place whilst your head is in the clouds and your hand is in someone else's pocket.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.programming
csiph-web