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

Language                     Ratio

-----------------------------------------------------------
Assembler                    1 to 1
Ada                          1 to 4.5
Quick/Turbo Basic            1 to 5
C                            1 to 2.5
Fortran                      1 to 3
Pascal                       1 to 3.5

< Source : Applied Software Measurement (Jones 1991) >

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

It's very famous issue. That's why using floating point operation is difficult.
Especially, round-off can make up to 0.5f erratum.
In calculation for drawing on pixels, round-off is frequently used - Do not consider blending and anti-aliasing. And even sum of two errata can make 1 pixel erratum. So, we should always keep this in mind when implement pixel-relative-calculation.

Here is example.

Line L passes point P0 and P1.
Drawing two lines those are orthogonal to L, L-symmetric, passes point P2, P3 respectively and length is R.

As you know, there two lines should be parallel.
But, in this case, we should calculate two end points - the results may be float type. To draw this we should make those as an integer value (usually by using round-off).
For each line, up to 0.5f erratum can exist. So, for two lines, up to 1 pixel erratum can be raised. So, when these two lines are drawn on the canvas, they may not be parallel.

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

[GNU] Issues of cross-compiling in GNU build system.  (0) 2011.04.21
[Tips] Cyclic Queue  (0) 2010.10.18
[SW] Questions to evaluate SW Engineer  (0) 2009.04.09
[Prog] Using so-called 'context' data structure.  (0) 2008.01.10
[Spec] DWARF2  (0) 2006.08.30
[[ 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날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
 

((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."

+ Recent posts