Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
perhaps requiring C and Eclipse, or a particular vendor's trial
development tools. An example available on the Olimex site uses 4000+
bytes to blink an LED.
What about those who are less maximalist?
I have written a short note showing an example LED-blinking assembly
language program and how to assemble and link using the GNU ARM tools
and how to burn it into flash using a JTAG adapter and OpenOCD. The
binary is about 100 bytes.
Even though this is an LPC group and the example is for the Olimex
STM32-P103 ARM Cortex M3 board, most of the information would also apply
to the LPC Cortex M3 chips.
http://pygmy.utoh.org/riscy/cortex/led-stm32.html
It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
tools are available for easy installation onto an Ubuntu 10.04 system at
http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
--
Frank
http://pygmy.utoh.org
ARM Cortex M3 assembly language example
Started by ●January 17, 2011
Reply by ●January 17, 20112011-01-17
Frank,
Excellent work. I haven't read all the details, but I've been using
GNU tools with OpenOCD for several years, presently on Ubuntu.
Perhaps with your example, more people will discover the power of Linux
for development of embedded systems.
Regarding comments: I don't recall having a problem using semicolons,
but that was a long time ago. Now I run the assembler through gcc,
enabling C style comments. I also use the pre-processor that allows
ifdefs, etc.
Below is an command line that is printed by my make utility. I do that
so I can always look back to see what was defined for a given source
file.
## In directory (/home/smead/svn/code/trunk/arm/libs/asm), assembling
with cmd (/usr/local/arm/bin/arm-elf-gcc -D__ASSEMBLER__ -x
assembler-with-cpp -Wa, -gstabs -c -DDEVICE!48 -DUSE_CRC_CRC16_TABLE
-DUSE_CRC_CCITT_TABLE -DUSE_CRC_XMODEM_TABLE -DUSER_smead -DHTTP_DEBUG
-I/home/smead/svn/code/trunk/arm/include-c99
-I/home/smead/svn/code/trunk/arm/libs
-I/home/smead/svn/code/trunk/arm/bootloader crt.s)
OK
I don't use ST processors yet, but am considering it. Could you share
your OpenOCD config file?
Thanks for submitting you work to this list.
DaveS
On Mon, Jan 17, 2011 at 1:09 PM, Frank Sergeant wrote:
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
>
> --
> Frank
> http://pygmy.utoh.org
>
>
>
Excellent work. I haven't read all the details, but I've been using
GNU tools with OpenOCD for several years, presently on Ubuntu.
Perhaps with your example, more people will discover the power of Linux
for development of embedded systems.
Regarding comments: I don't recall having a problem using semicolons,
but that was a long time ago. Now I run the assembler through gcc,
enabling C style comments. I also use the pre-processor that allows
ifdefs, etc.
Below is an command line that is printed by my make utility. I do that
so I can always look back to see what was defined for a given source
file.
## In directory (/home/smead/svn/code/trunk/arm/libs/asm), assembling
with cmd (/usr/local/arm/bin/arm-elf-gcc -D__ASSEMBLER__ -x
assembler-with-cpp -Wa, -gstabs -c -DDEVICE!48 -DUSE_CRC_CRC16_TABLE
-DUSE_CRC_CCITT_TABLE -DUSE_CRC_XMODEM_TABLE -DUSER_smead -DHTTP_DEBUG
-I/home/smead/svn/code/trunk/arm/include-c99
-I/home/smead/svn/code/trunk/arm/libs
-I/home/smead/svn/code/trunk/arm/bootloader crt.s)
OK
I don't use ST processors yet, but am considering it. Could you share
your OpenOCD config file?
Thanks for submitting you work to this list.
DaveS
On Mon, Jan 17, 2011 at 1:09 PM, Frank Sergeant wrote:
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
>
> --
> Frank
> http://pygmy.utoh.org
>
>
>
Reply by ●January 18, 20112011-01-18
How much difference does the start up code make between the size of an
application written in assembler and C? I have seen a comment by an
author saying that the start up code for C source projects significantly
increases the size of a small application byte file.
Howard
On 1/17/2011 3:09 PM, Frank Sergeant wrote:
>
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
>
> --
> Frank
> http://pygmy.utoh.org
application written in assembler and C? I have seen a comment by an
author saying that the start up code for C source projects significantly
increases the size of a small application byte file.
Howard
On 1/17/2011 3:09 PM, Frank Sergeant wrote:
>
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
>
> --
> Frank
> http://pygmy.utoh.org
Reply by ●January 18, 20112011-01-18
Am 18.01.2011 05:34, schrieb Howard Hansen:
> How much difference does the start up code make between the size of an
> application written in assembler and C? I have seen a comment by an
> author saying that the start up code for C source projects significantly
> increases the size of a small application byte file.
A simple C-startup consits of two loops:
data_ram = DATA_RAM;
data_rom = DATA_ROM;
for(i = 0; i < SIZEOF_DATA; ++i){
*data_ram++ = *data_rom;
}
and
bss = BSS;
for(i = 0; i < SIZEOF_BSS; ++i){
*bss++ = 0;
}
(DATA_RAM, DATA_ROM, SIZEOF_DATA, BSS and SIZEOF_BSS are defined in the
linker script.)
So one cannot blame C-startup for bloated programs :-)
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
> How much difference does the start up code make between the size of an
> application written in assembler and C? I have seen a comment by an
> author saying that the start up code for C source projects significantly
> increases the size of a small application byte file.
A simple C-startup consits of two loops:
data_ram = DATA_RAM;
data_rom = DATA_ROM;
for(i = 0; i < SIZEOF_DATA; ++i){
*data_ram++ = *data_rom;
}
and
bss = BSS;
for(i = 0; i < SIZEOF_BSS; ++i){
*bss++ = 0;
}
(DATA_RAM, DATA_ROM, SIZEOF_DATA, BSS and SIZEOF_BSS are defined in the
linker script.)
So one cannot blame C-startup for bloated programs :-)
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Reply by ●January 18, 20112011-01-18
--- In l..., Frank Sergeant wrote:
>
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse
If I use TECO, will my programs be smaller ?
;-)
, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
> --
> Frank
> http://pygmy.utoh.org
>
>
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse
If I use TECO, will my programs be smaller ?
;-)
, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
> --
> Frank
> http://pygmy.utoh.org
>
Reply by ●January 18, 20112011-01-18
--- In l..., Howard Hansen wrote:
>
> How much difference does the start up code make between the size of an
> application written in assembler and C? I have seen a comment by an
> author saying that the start up code for C source projects significantly
> increases the size of a small application byte file.
>
> Howard
Sure, it doesn't make much sense to have 256 bytes of startup code to support a 100 byte application.
But, if the application is of a size where C is the best way to write it, a minor amount of startup code isn't very significant.
High level languages are simply a time multiplier. A programmer can only write just so many lines of correct code per day and, in the past, this was thought to be about 100 lines. If a high level language reduces the number of lines of code in the application, it is a time multiplier. Assuming, of course, that the resulting code runs fast enough to implement the application.
I guess it can also be argued that high level languages are also easier to maintain and, in this regard, the HLL is a cost reducer.
It is certainly possible to gain much of the structure of a high level language with assembly language and macros. We certainly did that in the early days of the 8080, Z80 and 8086.
"It is possible by ingenuity and at the expense of clarity to do almost anything in any language. However, the fact that it is possible to push a pea up a mountain with your nose does not mean that this is a sensible way of getting it there."
Christopher Strachey
NATO Summer School in Programming
Paraphrased from Chapter 1 of "A Compiler Generator" by McKeeman, Horning and Wortman.
Richard
>
> How much difference does the start up code make between the size of an
> application written in assembler and C? I have seen a comment by an
> author saying that the start up code for C source projects significantly
> increases the size of a small application byte file.
>
> Howard
Sure, it doesn't make much sense to have 256 bytes of startup code to support a 100 byte application.
But, if the application is of a size where C is the best way to write it, a minor amount of startup code isn't very significant.
High level languages are simply a time multiplier. A programmer can only write just so many lines of correct code per day and, in the past, this was thought to be about 100 lines. If a high level language reduces the number of lines of code in the application, it is a time multiplier. Assuming, of course, that the resulting code runs fast enough to implement the application.
I guess it can also be argued that high level languages are also easier to maintain and, in this regard, the HLL is a cost reducer.
It is certainly possible to gain much of the structure of a high level language with assembly language and macros. We certainly did that in the early days of the 8080, Z80 and 8086.
"It is possible by ingenuity and at the expense of clarity to do almost anything in any language. However, the fact that it is possible to push a pea up a mountain with your nose does not mean that this is a sensible way of getting it there."
Christopher Strachey
NATO Summer School in Programming
Paraphrased from Chapter 1 of "A Compiler Generator" by McKeeman, Horning and Wortman.
Richard
Reply by ●January 18, 20112011-01-18
Hi,
For LPC17xx ARM Cortex-M3 assembly language example, try: http://embeddedfreak.wordpress.com/2009/08/09/cortex-m3-blinky-in-assembly/
Regards,
-daniel
--- On Tue, 1/18/11, Donald H wrote:
> From: Donald H
> Subject: [lpc2000] Re: ARM Cortex M3 assembly language example
> To: l...
> Date: Tuesday, January 18, 2011, 5:14 AM
>
>
> --- In l...,
> Frank Sergeant wrote:
> >
> > Most example programs for the ARM Cortex M3 appear to
> be fairly "heavy",
> > perhaps requiring C and Eclipse
>
> If I use TECO, will my programs be smaller ?
>
>
> ;-)
>
>
> , or a particular vendor's trial
> > development tools. An example available on the
> Olimex site uses 4000+
> > bytes to blink an LED.
> >
> > What about those who are less maximalist?
> >
> > I have written a short note showing an example
> LED-blinking assembly
> > language program and how to assemble and link using
> the GNU ARM tools
> > and how to burn it into flash using a JTAG adapter and
> OpenOCD. The
> > binary is about 100 bytes.
> >
> > Even though this is an LPC group and the example is
> for the Olimex
> > STM32-P103 ARM Cortex M3 board, most of the
> information would also apply
> > to the LPC Cortex M3 chips.
> >
> > http://pygmy.utoh.org/riscy/cortex/led-stm32.html
> >
> > It runs on Linux (even the 32-bit Ubuntu 10.04 live
> CD) and the GNU
> > tools are available for easy installation onto an
> Ubuntu 10.04 system at
> > http://pygmy.utoh.org/riscy/ (look for "The Tools
> Bundle").
> >
> >
> > --
> > Frank
> > http://pygmy.utoh.org
For LPC17xx ARM Cortex-M3 assembly language example, try: http://embeddedfreak.wordpress.com/2009/08/09/cortex-m3-blinky-in-assembly/
Regards,
-daniel
--- On Tue, 1/18/11, Donald H wrote:
> From: Donald H
> Subject: [lpc2000] Re: ARM Cortex M3 assembly language example
> To: l...
> Date: Tuesday, January 18, 2011, 5:14 AM
>
>
> --- In l...,
> Frank Sergeant wrote:
> >
> > Most example programs for the ARM Cortex M3 appear to
> be fairly "heavy",
> > perhaps requiring C and Eclipse
>
> If I use TECO, will my programs be smaller ?
>
>
> ;-)
>
>
> , or a particular vendor's trial
> > development tools. An example available on the
> Olimex site uses 4000+
> > bytes to blink an LED.
> >
> > What about those who are less maximalist?
> >
> > I have written a short note showing an example
> LED-blinking assembly
> > language program and how to assemble and link using
> the GNU ARM tools
> > and how to burn it into flash using a JTAG adapter and
> OpenOCD. The
> > binary is about 100 bytes.
> >
> > Even though this is an LPC group and the example is
> for the Olimex
> > STM32-P103 ARM Cortex M3 board, most of the
> information would also apply
> > to the LPC Cortex M3 chips.
> >
> > http://pygmy.utoh.org/riscy/cortex/led-stm32.html
> >
> > It runs on Linux (even the 32-bit Ubuntu 10.04 live
> CD) and the GNU
> > tools are available for easy installation onto an
> Ubuntu 10.04 system at
> > http://pygmy.utoh.org/riscy/ (look for "The Tools
> Bundle").
> >
> >
> > --
> > Frank
> > http://pygmy.utoh.org
Reply by ●January 18, 20112011-01-18
My start up file, crt.s, which does all the stack stuff, sets up trap
vectors, call functions to set up the clock and task manager results in an
object size of 348 bytes.
DaveS
On Mon, Jan 17, 2011 at 8:34 PM, Howard Hansen wrote:
> How much difference does the start up code make between the size of an
> application written in assembler and C? I have seen a comment by an author
> saying that the start up code for C source projects significantly increases
> the size of a small application byte file.
>
> Howard
>
> On 1/17/2011 3:09 PM, Frank Sergeant wrote:
>
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
>
> --
> Frank
> http://pygmy.utoh.org
>
>
vectors, call functions to set up the clock and task manager results in an
object size of 348 bytes.
DaveS
On Mon, Jan 17, 2011 at 8:34 PM, Howard Hansen wrote:
> How much difference does the start up code make between the size of an
> application written in assembler and C? I have seen a comment by an author
> saying that the start up code for C source projects significantly increases
> the size of a small application byte file.
>
> Howard
>
> On 1/17/2011 3:09 PM, Frank Sergeant wrote:
>
> Most example programs for the ARM Cortex M3 appear to be fairly "heavy",
> perhaps requiring C and Eclipse, or a particular vendor's trial
> development tools. An example available on the Olimex site uses 4000+
> bytes to blink an LED.
>
> What about those who are less maximalist?
>
> I have written a short note showing an example LED-blinking assembly
> language program and how to assemble and link using the GNU ARM tools
> and how to burn it into flash using a JTAG adapter and OpenOCD. The
> binary is about 100 bytes.
>
> Even though this is an LPC group and the example is for the Olimex
> STM32-P103 ARM Cortex M3 board, most of the information would also apply
> to the LPC Cortex M3 chips.
>
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html
>
> It runs on Linux (even the 32-bit Ubuntu 10.04 live CD) and the GNU
> tools are available for easy installation onto an Ubuntu 10.04 system at
> http://pygmy.utoh.org/riscy/ (look for "The Tools Bundle").
>
> --
> Frank
> http://pygmy.utoh.org
>
>
Reply by ●January 18, 20112011-01-18
... in the safety critical world, you're lucky to get two lines a day (once
documentation and testing is taken into account).
----- Original Nachricht ----
Von: rtstofer
An: l...
Datum: 18.01.2011 06:22
Betreff: [lpc2000] Re: ARM Cortex M3 assembly language example
> --- In l..., Howard Hansen wrote:
> >
> > How much difference does the start up code make between the size of an
> > application written in assembler and C? I have seen a comment by an
> > author saying that the start up code for C source projects significantly
> > increases the size of a small application byte file.
> >
> > Howard
> >
> > Sure, it doesn't make much sense to have 256 bytes of startup code to
> support a 100 byte application.
>
> But, if the application is of a size where C is the best way to write it, a
> minor amount of startup code isn't very significant.
>
> High level languages are simply a time multiplier. A programmer can only
> write just so many lines of correct code per day and, in the past, this was
> thought to be about 100 lines. If a high level language reduces the number
> of lines of code in the application, it is a time multiplier. Assuming, of
> course, that the resulting code runs fast enough to implement the
> application.
>
> I guess it can also be argued that high level languages are also easier to
> maintain and, in this regard, the HLL is a cost reducer.
>
> It is certainly possible to gain much of the structure of a high level
> language with assembly language and macros. We certainly did that in the
> early days of the 8080, Z80 and 8086.
>
> "It is possible by ingenuity and at the expense of clarity to do almost
> anything in any language. However, the fact that it is possible to push a
> pea up a mountain with your nose does not mean that this is a sensible way
> of getting it there."
>
> Christopher Strachey
> NATO Summer School in Programming
>
> Paraphrased from Chapter 1 of "A Compiler Generator" by McKeeman, Horning
> and Wortman.
>
> Richard
>
----- Original Nachricht ----
Von: rtstofer
An: l...
Datum: 18.01.2011 06:22
Betreff: [lpc2000] Re: ARM Cortex M3 assembly language example
> --- In l..., Howard Hansen wrote:
> >
> > How much difference does the start up code make between the size of an
> > application written in assembler and C? I have seen a comment by an
> > author saying that the start up code for C source projects significantly
> > increases the size of a small application byte file.
> >
> > Howard
> >
> > Sure, it doesn't make much sense to have 256 bytes of startup code to
> support a 100 byte application.
>
> But, if the application is of a size where C is the best way to write it, a
> minor amount of startup code isn't very significant.
>
> High level languages are simply a time multiplier. A programmer can only
> write just so many lines of correct code per day and, in the past, this was
> thought to be about 100 lines. If a high level language reduces the number
> of lines of code in the application, it is a time multiplier. Assuming, of
> course, that the resulting code runs fast enough to implement the
> application.
>
> I guess it can also be argued that high level languages are also easier to
> maintain and, in this regard, the HLL is a cost reducer.
>
> It is certainly possible to gain much of the structure of a high level
> language with assembly language and macros. We certainly did that in the
> early days of the 8080, Z80 and 8086.
>
> "It is possible by ingenuity and at the expense of clarity to do almost
> anything in any language. However, the fact that it is possible to push a
> pea up a mountain with your nose does not mean that this is a sensible way
> of getting it there."
>
> Christopher Strachey
> NATO Summer School in Programming
>
> Paraphrased from Chapter 1 of "A Compiler Generator" by McKeeman, Horning
> and Wortman.
>
> Richard
>
Reply by ●January 18, 20112011-01-18
What's the source of that claim?
On Tue, Jan 18, 2011 at 7:41 AM, Nicholas Lusty wrote:
> ... in the safety critical world, you're lucky to get two lines a day (once
> documentation and testing is taken into account).
>
> ----- Original Nachricht ----
> Von: rtstofer >
> An: l...
> Datum: 18.01.2011 06:22
> Betreff: [lpc2000] Re: ARM Cortex M3 assembly language example
> >
> >
> > --- In l... , Howard
> Hansen wrote:
> > >
> > > How much difference does the start up code make between the size of an
> > > application written in assembler and C? I have seen a comment by an
> > > author saying that the start up code for C source projects
> significantly
> > > increases the size of a small application byte file.
> > >
> > > Howard
> > >
> > >
> >
> > Sure, it doesn't make much sense to have 256 bytes of startup code to
> > support a 100 byte application.
> >
> > But, if the application is of a size where C is the best way to write it,
> a
> > minor amount of startup code isn't very significant.
> >
> > High level languages are simply a time multiplier. A programmer can only
> > write just so many lines of correct code per day and, in the past, this
> was
> > thought to be about 100 lines. If a high level language reduces the
> number
> > of lines of code in the application, it is a time multiplier. Assuming,
> of
> > course, that the resulting code runs fast enough to implement the
> > application.
> >
> > I guess it can also be argued that high level languages are also easier
> to
> > maintain and, in this regard, the HLL is a cost reducer.
> >
> > It is certainly possible to gain much of the structure of a high level
> > language with assembly language and macros. We certainly did that in the
> > early days of the 8080, Z80 and 8086.
> >
> > "It is possible by ingenuity and at the expense of clarity to do almost
> > anything in any language. However, the fact that it is possible to push a
> > pea up a mountain with your nose does not mean that this is a sensible
> way
> > of getting it there."
> >
> > Christopher Strachey
> > NATO Summer School in Programming
> >
> > Paraphrased from Chapter 1 of "A Compiler Generator" by McKeeman, Horning
> > and Wortman.
> >
> > Richard
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
On Tue, Jan 18, 2011 at 7:41 AM, Nicholas Lusty wrote:
> ... in the safety critical world, you're lucky to get two lines a day (once
> documentation and testing is taken into account).
>
> ----- Original Nachricht ----
> Von: rtstofer >
> An: l...
> Datum: 18.01.2011 06:22
> Betreff: [lpc2000] Re: ARM Cortex M3 assembly language example
> >
> >
> > --- In l... , Howard
> Hansen wrote:
> > >
> > > How much difference does the start up code make between the size of an
> > > application written in assembler and C? I have seen a comment by an
> > > author saying that the start up code for C source projects
> significantly
> > > increases the size of a small application byte file.
> > >
> > > Howard
> > >
> > >
> >
> > Sure, it doesn't make much sense to have 256 bytes of startup code to
> > support a 100 byte application.
> >
> > But, if the application is of a size where C is the best way to write it,
> a
> > minor amount of startup code isn't very significant.
> >
> > High level languages are simply a time multiplier. A programmer can only
> > write just so many lines of correct code per day and, in the past, this
> was
> > thought to be about 100 lines. If a high level language reduces the
> number
> > of lines of code in the application, it is a time multiplier. Assuming,
> of
> > course, that the resulting code runs fast enough to implement the
> > application.
> >
> > I guess it can also be argued that high level languages are also easier
> to
> > maintain and, in this regard, the HLL is a cost reducer.
> >
> > It is certainly possible to gain much of the structure of a high level
> > language with assembly language and macros. We certainly did that in the
> > early days of the 8080, Z80 and 8086.
> >
> > "It is possible by ingenuity and at the expense of clarity to do almost
> > anything in any language. However, the fact that it is possible to push a
> > pea up a mountain with your nose does not mean that this is a sensible
> way
> > of getting it there."
> >
> > Christopher Strachey
> > NATO Summer School in Programming
> >
> > Paraphrased from Chapter 1 of "A Compiler Generator" by McKeeman, Horning
> > and Wortman.
> >
> > Richard
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
