It's very-well-known tip for cyclic queue!
Here is pseudo code!
(Even if this is very -well-known and not difficult to think of, it's worth to remind.)

TYPE Q
    item[SZ] // queue array
    i        // current index
...

FUNC addQ (q, item)
// This is Naive way.
    item[q.i] = item
    if (q.i >= SZ) than q.i = 0

// This is well-known way
    item[q.i] = item
    q.i &= SZ-1 // For this, SZ should be (2^n (n>0))

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

Let's consider two different level - Coder, Programmer.
Coder is engineer who can modify and implement not-big-size source code under the given SW architecture, requirement and environment.
Programmer is engineer who can define requirements, design SW architecture, analysis and fix system-wide-issues.

At first, we decide which level of SW engineer should be recruited.

To recruit Coder, following questions may be enough.
- Questions about language syntax and it's application.
- Simple problem-solving-ability (ex. simple optimization and so on.)
- Coding test. (ex. implement linked list, Queue or Stack etc)

But, to recruit Programmer, you may need additional questions to know about his/her programming policy and values.
For example,
- What's your opinion about 'modularity'?
- What is 'software layer' and what it should be?
- Please tell me about 'information hiding'

But, someone may give well-known answer that may come from books. So, detail and concrete question should be follows.
For example, followings can be asked after question "What's your opinion about 'modularity'"
- Then, What should good modular architecture be?
- Show example of good modular architecture.
- What kind of design can be used to connect between modules.
- What is good interface design to support modularity?
- Please design linked list with C language focusing on modularity.

... I am not sure that this kind of evaluation can be possible in practical. But...

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

Sometimes, so-called 'context' data structure is used to handling set of related information. And this context data tends to be required as parameter by various functions. Here is pros and cons.

Pros:
- It is easy to handle lots of related data - data allocation and free etc.
- We can save costs of parameter passing; Passing context is enough.

Cons:
- It is difficult to know which one is input and which one is output, because whole context is passed as parameter. This decrease readability very much.
- Usually, context is passed as parameter to lots of functions. So, just like 'global' data, it is very difficult to trace the value-change-history. That is, debugging/maintaining becomes difficult.

One good way to using context structure; Only very few modules can change/modify context data. And others only can read this one. Than, lot's of issues in "Cons" can be overcome.

[[ 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날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]

[From DWARF Specification Version 2.0]

* Ambiguity in the Spec.
At first, let's see followings.

[Extracted from spec. page 66]
DW_CFA_def_cfa_offset takes a single unsigned LEB128 argument representing an offset -- (*1). The required action is to define the current CFA rule to use the provided offset (but to keep the old register).

[Extracted from spec. page 105]
fde + 17 DW_CFA_def_cfa_offset (<fsize>/4) -- (*2) ; assuming <fsize> < 512

As you can see above, in (*1) argument is just an offset. But in (*2), <fsize> is divided by '4'. So, I think there is conflict in those part.

In 'libdwarf', as (*1), it uses offset value itself. But, dwarf information generated by ADS1.2 compiler is obeys rule (*2) - offset * 4 (data alignment factor).

* How can we get Die from PC without 'Arrange Section'.

In this case, we can get CU Die from CU Header. And then, the result of sorting them into 'lowpc' order, can be used.

* Optimizing out local stack variable.

Unlike static or global variable, dwarf defines valid range for the local stack variable. That is, stack variable is valid only in this range. This may make mismatch between code and dwarf information; Sometimes, we seem to know value of variable when we look at the code, but in actual dwarf information, the variable is not valid yet, or optimized out. So, we cannot know it. Yes, this is totally compiler dependent.

Here is example.

funcA(...)
{
    int a = 8;
    ...
    a = 10;   // --- (*)
    ...
}

"int a=8" is stored at NVRAM. So, compiler don't need to keep this value in memory. Therefore, before "a=10;", this value may not be assigned into the stack - that is, there is not relative dwarf information. As a result, we cannot read value "a" by reading register of memory. (In practice, this kind of stuffs often happens in ADS1.2 compiler.)

* Handling included source.
See follows.

a.c
    ...

b.c
    ...
    #include "a.c"
    ...

(ASSUMPTION : 'a.c' is not compiled separately)

In ADS1.2, 10th line of 'a.c' is regarded as 10th line of 'b.c'. So, there are two 10th lines in the dwarf information. I think some compiler may handle this case correctly. But, in ADS1.2, dwarf information is generated unexpectedly.

+ Recent posts