[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

Here are unexpected exceptions that can be occurred in SW(ARM).

  * Data Abort
  * Prefetch
  * Undefined Instruction
  * Divide by zero.

And here is sample code to raise these exceptions.

#pragma O0   /* disable all optimization */

typedef void (*_FuncT)(void);
void _test_data_abort(void)
    int   c;
    int*  p = (int*)0xdeaddead;
    c = *p;

void _test_prefetch_abort(void)
    _FuncT  f;
    f = (_FuncT)0xdeaddead;

static const int _undef_inst = 0xff0000ff;
void _test_undefined_instruction()
    _FuncT f;
    f = (_FuncT)(&_undef_inst);

(divide by zero) is omitted

In '_test_undefined_instruction()' , variable '_undef_inst' is located at 4byte-aligned-position. So, program mode becomes ARM mode when "f=(_FuncT)(&_undef_inst);" is executed - BX to 4byte-aligned-address (address & 0x1 == 0x00).

"MSB <--FFxxxxxx--> LSB" area is 'undefined instruction' area in ARM instruction. So, we can make endian-independent-'undefined instruction' by setting '_undef_inst' as 0xff0000ff.

'Domain > ARM' 카테고리의 다른 글

[ARM] Sample code for unwinding stack with DWARF2 information.  (0) 2010.04.07
[ARM] Sample code for unwinding stack in Thumb mode.  (0) 2010.04.07
[ARM] Unwinding Stack.  (0) 2009.09.15
[ARM] Long jump.  (0) 2007.06.05
[ARM] .init_array section  (0) 2007.03.18
[ARM] Exception generating codes...  (0) 2006.05.13
블로그 이미지


Tag Arm

댓글을 달아 주세요

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

It seems obvious that hardware specific software should be layered with unified interface.
This is very important to portability and debugging. In addition, this can help simulate hardware functionality in other platform - desktop PC. This is something like "Porting to PC". Programming and debugging on PC platform can increase productivity very much. Can you understand how important this is?
(Please refer "Linux" device driver interface. This is very good example!)
블로그 이미지


댓글을 달아 주세요

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

▶ Performance gab between using 'enum' and "using '#define' in Visual C++ 7.0
Environment : CPU: Intel 2.8G

Using enum:
    Number of enum items := 100,000 -> compiling takes very long time.
    Number of enum items := 10,000 -> very quick.
Using define
    Very quick even if number of defined items reaches 100,000.

Experimentally, if number of enum items are larger than specific threshold, compiling performance of VC++ 7.0 drops dramatically. So in this case, we would better to change 'enum' into '#define'.

▶ Order of finding 'include directory' in VC++ 7.0
"highest priority is directory where currently issued file is in.".
For example, lets consider following directory structure.

directory : xxx/src
=> a.c, c.h
directory : xxx/inc
=> b.h, c.h

(Let's assume that "xxx/inc" is added at "additional include directory").
"xxx/inc/b.h" and "xxx/inc/c.h" is used to compile "a.c". Even though compiler try to compile "a.c", "b.h" is issued file during parsing "b.h". And, "b.h" includes "c.h". So "c.h" in the directory where "b.h" is in, is included, because currently issued file is "b.h".

▶ Case that '.c' file and '.cpp' file whose basename are same, are in one VC Project in Visual 2005 Express C++.
For example, if there are 'a.c' and 'a.cpp' in one project, MSVC recognizes only '.cpp' file (based on experimental result). (I think the reason is that default compiler of VC is 'cpp' compiler.)
So, even if we modify 'a.c' and build, nothing is compiled because MSVC keep it's eyes on 'a.cpp' - it is not changed. (--> It's MSVC's bug!!)

▶ There is no way to compile one file with several different options in VC project. So we should use 'command line' to do this.

'Domain > Win32' 카테고리의 다른 글

[Win32][Tips] Creating Window...  (0) 2007.06.27
[Win32] IME Active중 VK Code얻기  (0) 2007.06.25
[Win32] 한글 입력하기  (0) 2007.06.23
[Tips] Cross-Compiling on Windows for Linux  (0) 2007.06.20
[Tips] cygwin 'make' issue  (0) 2007.06.13
[VC][Tips] 2005 express  (0) 2006.04.12
블로그 이미지


댓글을 달아 주세요

[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

((To avoid misunderstanding) I am also application engineer.)
Application engineer tends to ignore HW characteristics. But, without HW, SW is useless. Even application engineer in embedded software, would better to know basic stuffs about low-layer. Here are some examples about considering these low-layer characteristics. These examples are to appeal to application engineer.

* Each assembly code line may spend different number of CPU clocks. So, counting assembly code line is useless to check CPU performance.
* Optimized code for "2 CPU + 1RAM" is totally different from the one for "2 CPU + 2 RAM for each". Besides, DMA, Bus arbiter etc may also affect to code.
* In some cases, using compressed data is faster than uncompressed one. For example, using highly-compressed-RLE data on the platform which has very-fast-CPU but slow NVRAM. In this case, dominate factor of performance is "performance of accessing NVRAM". So, compressed data has advantage on this. Besides, overhead for uncompress is very low in case of RLE.

Point in here is, "In embedded environment, even application engineer needs to know about it's HW platform where software runs on."

블로그 이미지


댓글을 달아 주세요