컥.. 이런이런.. 한참을 헤맨끝에 문득 떠오른 생각...

"음... 혹시 빌드 옵션에서 본 call 방식때문에 그런가.. ㅡ_ㅡ;;;"

빌드 옵션에 들어가보니 near call/near data인가??? 머 이걸로 되어있었다.
MP3코드가 좀 길다보니 near call은 안되는 것도 몇개 있겠다 싶어서 far call/data로
수정하고 링크했더니 링크가 되공.. ㅡ_ㅡ;;;
머 이제 보드에 MP3 데이터를 올려야 하니, 내가만든 C55용 툴을 개조해서 C67용으
로 수정하고 메모리에 올려서 테스트 하는데,
얼래... 계속 MP3 Frame이 잘못됬다는 에러가 나네.. ㅡ_ㅡ;;;
산넘어 산이라고, 것참 만만한게 아니구만 쩝쩝.

죽어라 삽질끝에, 디버깅하다가 데이터가 이상해지는 걸 발견... 함수에서 넘겨받은
파라메터의 값이 실행도중에 바뀌는 것이다. 역 어셈해봐도 딱히 이거다 짐작가는건
없고... 근데 웃기는건 그 함수에서 다른 함수로 파라메터를 넘겨주면 넘겨받은 함수
의 파라메터는 변하지 않은 정상적인 값으로 나옴.

음냥, 결국 C67의 디버그는 못믿겠다는 결론에 봉착하고 메모리를 살피던 도중, 올라
간 메모리가 먼가 이상함을 발견했다.
자세히 들여다 보니, 헉... C55는 데이터를 Word 단위로 받기때문에 C67도 그런줄
알고 Word 단위로 데이터를 만들어서 CCS로 로딩했더니, 이게 실은 Dword로 읽어
들여 상위를 모두 0x0000으로 체웠던것이다.
그러니 프레임 에러가 날 수 밖에.. ㅡ_ㅡ;;;

툴 수정후에 다시 로딩해서 실행하니, 프레임 에러는 없음.
으으... 토하겠다 ㅡㅠㅡ;;;;
머가 이렇노..
Boot Code를 분석하던 중에 LDR과 MOV의 명령을 보게 되었다.
ARM 문서를 보니 둘다 레지스터에 값을 넣는거던데.. ㅡ_ㅡ;;;
이래 저래 서로 명령어를 스위칭해가면서 테스트 했는데 실패...
웹상에서 아는 분께 물었더니,

LDR ==> 메모리에서 레지스터로 값을 넣음.
MOV ==> 레지스터 또는 Immediate를 레지스터로 넣음.

이었던 것이다.
음냥.. 근데 여기서 이상한걸 발견할 수가 있는데, LDR과 MOV 모두 12bit Address
bit를 가지고 있다.
근데, LED 포트는 0x90040000로 표기되는 32bit인데 어떻게 LDR r0, =0x90040000
를 통해 레지스터에 32bit 값을 넣을 수 있는 것일가??

arm-linux-gcc로 일단 컴파일 링크를 거친다음 arm-linux-objdump로 역어셈블해본
결과 위의 코드는 아래와 같이 되어있었다.

80c8: e59f0068 ldr r0, [pc, #68] ; 8138 <LedFlashing+0x1c>
.....
8138: 90040000 andls r0, r4, lr

컥... 결국 메모리에 0x90040000를 어딘가에 써넣고, LDR 명령에는 해당 OFFSET의
메모리 Address만 넣어둔 것이었다 @0@/~~
쿠.. 쿨럭..;;
저.. 저런식인가.. ㅡ_ㅡ;;;
으으.. 나의 허접한 ARM 어셈실력으로 메뉴얼을 뒤져가며 삽질한 결과...
드뎌 LED가 라운드로빈되면서 켜지기 시작했다.
하려하는 구체적은 생각은 있는데, 어셈명령을 몰라 일단 생각나는 x86 어셈을 마구
난타한다음 컴파일 실행 @0@/~
역시나



!!!

눈물을 줄줄 흘리면서 Linux 커널에 있는 .S 파일을 뒤져서 보던중 BLE 란놈을 발견
하고 문서를 뒤진결과 B + 조건 의 형태로 구성되어있는 명령어들을 발견 @0@/~~
코딩후 바로 실행~~
오오~~ LED가 돌아가는걸 확인 할 수 있었다.
아아.. 드뎌 한 걸음 땠구나... ㅡ0ㅠ..
Flash에 구워서 되는걸 확인했으니, 이제 슬슬 해보면 될꺼 같다.
흐믓하군. ㅋㅋ
홧팅 >ㅁ</~
으으.. ㅡ_ㅡ;;; 왜일케 복잡한지... 믿었던 문서에 약간 미비한점도 있고...
여튼 이래 저래 하다보니 결국 크로스 컴파일러를 만들었다.
근데, 이놈도 마찬가지로 링크할때 바로 binary로 링크가 안되고 ELF로 링크가
되었다. binary를 사용하게 포멧을 binary로 줬더니 ARM링크할때는 ELF말고는
안된다는 에라 메시지가 나온다.
힘들게 컴파일 했더니만, 결국 GNUARM과 같은 결과가 나왔다.
일케되면 GNUARM을 걍 설치하고 PATH만 잡아주는거랑 같은결관데.. ㅡ0ㅠ/~
완전 생쇼를 했군... ㅡ_ㅡ;;;
머 그래도 제대로 설치 됬으니, 그것 하나는 다행인거 같고...
부트로더 같은거 만들려면... 순수 Binary가 필요한데 멀로 만드나...
ObjCopy라는게 있긴하던데, 이걸로 만드는감...
일단 낼 또 한번 뺑이를 쳐봐야 겠군.

오.. 글고 신기한건, 어셈 파일 형식인데 .S라는 확장자를 가지고 내부적으로는 C파일
전처리기 + 어셈코드 인거 같다.
어셈코드안에 #include 가 있는걸 보니...
으음.. 일케되면 걍 쓰면 된다는 결론이 나오네...

좋구로.. ㅋㅋㅋ
아.. 야심하군. 자야긋다.
홧팅 @0@/~~
쿠오~ 오늘 KESL 사이트를 뒤지다가
Cygwin에서 소스를 다 받아서 크로스 컴파일러를 만드는 문서를 구했다.
문서에 보니깐 테스트까지 해봤다고 해서, 속는 셈 치고 해봤더니
얼래.. ㅡ_ㅡ;;
gcc와 glibc가 만들어지는거 까지 확인했다.





!!!

이것만 되면 또 열심히 삽질하면서 플래쉬 굽고 리셋하고를 반복하겠군.
아아.. x86 커널 만들면서 다시는 안하겠다고 다짐했는데.. ㅡ_ㅡ;;;
시간이 좀 지나니 또 관심이 가는것이... 으으.. ㅡ_ㅠ...
일단 어셈코드부터 익숙해져야 겠다.
다 알 필요는 없지만 부트 코드랑 어셈 함수 정도는 만들 수 있어야 나중에 편해지니
까 고정도까지만 해둬야징...

여튼 좋구나아아아아~~~
쿠하하핫 @0@/~
음메... Cygwin과 GNUARM의 조합으로 구축해 보려던 환경은 오늘 실패로 끝났다.
으으... 설정파일 같은걸 시도하다가 결국 실패하여 파일을 한 폴더에 몰아넣는
'하드코어' 테크닉을 구사하여 머 실행까지는 시켰는데... ㅡ_ㅡ;;;
문제가 3가지 정도 있었다.

1. library 파일을 못찾는다.
2. include 파일을 못찾는다.
3. elf 파일 포멧 말고는 못만든다. (난 Binary 파일하고 coff 파일이 필요한데.. ㅡ_ㅡ)

쿠.. 쿨럭..;;;
걍 리눅스 깔아서 거기서 쓸까나.. ㅡ_ㅡ;;;;
요즘 또 ARM쪽에 문서를 보기 시작했는데, 이놈이 참 재밌는 구조를 하고 있다.
특히 IRQ위에 상위 Fast IRQ인가 하는게 더 있던데...(명칭 불확실) IRQ보다 우선순위
가 높아서 IRQ가 발생한 시점에도 Fast IRQ가 선점가능하다.
그리고 운영 모드도 여러 모드가 있어서 상당히 세분화 되있는듯한 느낌을 받았는데,
인상적인건 각 모드마다 banked register라는게 있어서 모드가 변경될때 이 레지스터
들은 이전 모드에서 사용하는 레지스터가 아니라는 것이다. @0@/~
오우~ 얼마나 헷갈리는 이야기인가.. ㅡ_ㅡ;;;
머 여튼 뺑이 쳐보면 알겠지.. ㅋㅋ
글고 어셈 명령이 좀 특이하던데, 어셈명령하나로 여러개의 레지스터에 줄줄이 넣고
빼고 할 수 있는거 같넹.
스택에 줄줄이 넣고 빼던데 이걸 사용하면 걍 스택에 넣는걸로 해서 Task Switching
을 구현할 수 있을꺼 같다.
쿠핫핫핫핫~
뺑이다 뺑이 @0@/~~
아래 바로가기 누르기

GNU ARM
컥..;;; 소스를 열심히 갖다 붓고 컴파일 에라를 잡은다음 링크를 거는 순간...
또 억장이 무너지는.. ㅡ_ㅠ;;;
살포시 떠오르는 빨간색의 링크 에라는 정체를 알 수 없는 문제를 ㅡ_ㅡ;;;;
머 오브젝트 파일에 특정 헥사값을 적고 빨간색으로 메모리 블럭이 머 어쩌구 이런
에라던데... ㅡ_ㅡ;;;;
참으로 당황스럽군.
Endian도 똑같고 각 변수 키워드들의 메모리 크기 같은것도 거의 차이가 없어서
금방될 줄 알았는데......
우우... 먼일일까나...
DSP는 역시 만만하게 볼 께 아닌거 같다.
ㅠ_ㅠ/~~ 크윽...
오늘 하루종일 삽질한 결과가 드뎌 나왔다.
EDMA하고 MCBSP를 오만 삽질끝에 드뎌 연결한것이다. @0@/~~
사인파가 삘삘 거리면서 스피커로 나오고 있다. ㅡ_ㅡ;;;;;
얼마나 해멨는지.. 말도 몬한다. ㅡ0ㅠ...
분명 XEVT0로 신호가 와서 EDMA가 사인파 데이터를 AD535쪽으로 퍼줘야 함에도 불
구하고, 전혀 소리가 안나는 것이다.
그리고 웃긴건, 간혹가다가 Transfer가 되고 그러고 난 뒤에는 AD535 초기화 실패..
잇단 코드 붕괴(??) ㅡㅠㅡ;;;;;

당체 먼일인지...

처음에는 EDMA쪽 설정이 잘못된줄 알고 죽어라 설정을 바꿨으나 똑같은 결과..
그나마 Transfer 갯수를 줄이면, 코드 붕괴(??)가 덜됨.. ㅡ_ㅡ;;;
일단 EDMA의 오동작으로 내맘대로 정하고 잠깐 쉬다가 다시 생각해보니 말도 안됨.

그리 해메다가 구석에 짱 박혀있는 책을 발견하고 뒤짐. 음냥.. 별 내용 없음 ㅡㅠㅡ;;;
또 한참을 삽질하고 MCBSP의 XINT를 강제로 Enable도 시켜보고 별 삽질 다했으나
결과는 나의 장렬한 전사. >ㅁ</~~

낡은 책을 한참을 뒤지던 끝에 대략 다음과 같은 간단한 문구 발견
"This is same as send to AD535 Dummy Data..."
쿨럭.. 번쩍이며 내 뒷골을 때리는 생각과 동시에 눈에 들어오는 코드...
EDMA를 Enable하고 났으니 이제 본격적으로 XEVT0를 발생시키기 위한 Trigger가
필요했던 것이다.

아아아아아아앍~~~ @0@/~~
그래서 걍 더미 데이터를 딱 나리자 마자 걍 소리남.. ㅡ_ㅡ;;;;
우이 씨...
왜이리 멍청한걸까?? ㅡㅠㅡ;;;;

자.. 그람 좀 쉬어볼까나... ㅋㅋㅋ
C6711 Chip의 Cache는 상당히 복잡한 구조를 가지고 있는거 같다.

L1, L2 Cache 간의 coherence는 snoop 커맨드로 지들이 알아서 동기화를 하는거 같
다.
L2, external 간의 coherence는 지들이 알아서 하는게 아니라 내 책임이란다. ㅡ_ㅡ;;
쿨럭.. 그래서 다음과 같은 상황에서는 앞서 아래와 같이 먼저 하라고 권고한다.

periperal -> external ram dma transfer 후 CPU가 buffer를 읽어야 할때
-> L2 write back Invalidate
CPU가 buffer를 조작 후 external ram -> periperal로 Transfer 할때
-> L2 write back

글고 CPU와 EDMA간에 external memory를 통한 array transfer를 할 시, array는
-> cache line 크기의 배수
-> cache line 경계에 정렬
되어야 한댄다. ㅡ_ㅡ;;;

이제야 지난번에 내가 EDMA로 external memory -> external memory로 transfer
를 했을때, 안됬는지 이유를 대강(??)알겠다.
쿨럭..;; 복합적인 이유였군.. @ㅠ@/~~
으으... 요즘 MP3처리때문에 여러 책들을 뒤지고 있다. 머 뒤지기만 할 뿐 크게 깨닫지
를 못하고 있어 상당한 에라지만... 언젠가는 도가 터질날이 있겠지...
우웅... kkamaugi 커널 만들때도 일케 빡시지는 않았는데...
그때는 OS에 대해 잘 몰라서 그걸 이해하는데 빡셨을뿐, Audio 처리는 알고리즘에
이해도 힘들고 구현은 더 빡신.. ㅡ_ㅡ;;;;
으으.. 여튼 큰일이다. 큰일 쩝쩝..
머 열심히 하는 수 밖에...
홧팅 @0@/~~
커억... 지난번에 DSP 보드는 Big Endian에 Word Addressing을 지원하는 칩이었는
데, 이번놈은 상당히 재밌다. 그냥 PC같은 Little Endian에 Byte Addressing을 지원
하고, 더 충격적인것은 long이 8byte라는 것이다. ㅡㅠㅡ;;; 쿨럭..
같은 dsp인데 일케 다를수가... 가장 충격적인것은....
이놈이 달고있는 ADC가 8khz짜리라는 것이고, 11khz까지 된다고는 되어있으나,
지금 보드 문서를 뒤지고 있는데, Clock Generator를 건드릴 방법이 없다는...
컥.. 이놈은 전화기쪽하고 관계된 일을 하는 놈인가?? ㅡ0ㅜ/~~
완전 음질이 전화기 음질, 그리고 잭은 스테레오 잭이지만, 출력 아웃풋은 모노인거
같은데, 모노를 그냥 스테레오 잭에 실어서 날리는거 같다.
아아~ 몬산다 몬살아... 소스도 손봐야 되고, Sample rate도 변환을 해줘야 할꺼 같다.
험난한 길이군.. ㅡ0ㅠ/~~
컥... 이런 이런... 같은 TI에서 나온 DSP인데... Endian이 모델마다 틀리게 설정되서
나오는 낭패를.. ㅡ_ㅡ;;; 얼마전까지 하던 DSP는 Big Endian이었는데, 이제는 Little
Endian으로.. ㅡㅠㅡ;;;; 크음.. 일단 걍 어디 하드웨어적인 셋팅으로 다시 Big Endian
으로 수정할 수 있는가 확인을 해봐야겠다. 소스를 수정할려니 좀 귀찮아야지 >_<
여튼 희한하군 @0@/~~
으으... 오늘도 안돌아가는 꼴통을 붙잡고 MP3관련 문서들을 죽어라 보고 있다. 그러나 오늘도 역시 처참한 패배.. ㅡ0ㅠ/~~ 당췌 잘 몰겄구만... 머 자꾸 여러문서를 뒤지다보니 깨닫는건 있지만...

그래도 아직 멀었다는 생각이 든다. 음성처리이론쪽으로 책을 한권 봐야 할듯도 하고... 혹시나 모를 다른 디코더 소스들도 뒤져서 어케 처리하는가 확인을 한번 해봐야 겠다.

정말 참.. 어렵구나.. 쩝쩝..
그래도 홧팅 @0@/~~
몇주째 계속 진행하고 있는 MP3의 디코딩이 역시 쉽지 않다. 오늘 시내에 갈일이 있어 교보문고에서 혹시나하며 책을 뒤지고 있었는데, MPEG에 대한 자료를 몇개 구할 수 있었다.

몇권을 뒤져본 결과 한권의 쓸만한 책을 찾았는데, MP3에 대한 간략한 설명만해놓아서, 크게 도움이 되지 않았다.

인터넷에서 자료를 찾을려고 했었는데, 내가 왜 책 생각을 못했을까...

이 기회에 책을 한권 사볼까나??
음.. 요즘 아는 선배가 내가 MP3 Decoder를 하는 사이 MP3 Encoder를 하게 되어서 같은 분야를 얼마동안 하게 되었다. 흠... 근데... 내가 Decoder할때 그렇게 찾아도 나오지 않던 자료들이... 선배는 쏙쏙 잘도 뽑아내는것이 아닌가?? @0@/~~
컥.. 이 무슨일인가.. 혹시나 내가 안가본 사이트인지 확인하니...

다 들렸던 곳이다.. ㅡ0ㅡ;;;;;;;;

머징... 근데 난 왜 자료를 못찾았을까나... 나의 검색능력은... 빵점이었던 것이다.
쿠.. 쿨럭;;;;;; ㅡ_ㅡ;;;;;;
근데 참 선배들도 대단하지... 어케 그 많은 문서중에 그런걸 찾아냈을까나...
역시.. 내공.. 200%군.. ㅋㅋㅋ
난 Decoder 소스도 x86껄 찾아서 포팅한다고 쌩쑈를 했는데... 소스도 보니까 있공...
컥.. >_<.... 머.. 그래도 포팅하면서.. DSP칩에 대해 먼가 좀 알긴했지만...
삽질했다는 것 만큼은 변함이 없네. 음냥...

네트워크의 시대

지금 우리에게 가장 중요한건 원하는 자료를 얼마나 빨리 찾아내는것이 아닐까하는 생각이 든다.

여튼 홧팅이다. @0@/~~~

요즘 회사일때문에 한참 폭발코딩중이다. 그중에 하나가 스크립트 파일을 읽어서 조건에 맞는 어떤일을 해주는 스크립트 프로그램인데, 이게 아주 예술(??)이다.

학교를 얼마 다니지 못하고 일하러 끌려온(??) 나로서 오토마타니 컴파일러니.. 이런 것들에 대한 지식이 있을리 만무하다. ㅡ0ㅡ/~~ 그나마 예전에 x86 Assembler를 만든다고 책을 좀 봐놓은게 있어서 구현하는데 무리를 느끼는건 아니지만, 그래도 체
계적인 지식이 부족하다고 생각한다. (학교로 돌아가면 공부를 열심히 해야 겠군..)

그동안 회사에서 한 일들이 그렇게 복잡도를 요구하는것이 아니어서 시간에 쪼달릴 뿐 머리를 그렇게 많이 쓰게 만드는건 없었건만, 이건.. 아까 언급했듯.. 아주 예술이다.

내가 원체 프로그램 기능 추가하고 머하고 하는걸 싫어하기 때문에, 이번 프로젝트는 추가적인 기능을 하는 놈을 아예 스크립트로 빼버려서 텍스트만 밀어넣고 데이터만 몇개 주면 조건에 맞추어 추가적인 기능을 하는 놈을 실행해 버리는.. 그런 대찬 프로젝트를 계획했다.

한 3일해서 아래의 if/else if/else문을 약간의 문제를 남기로 처리하는데까지 구현을 했는데, 역시 머리가 윽시로 아프다. ㅡ0ㅠ/~~


 

if( ( ( NODEID == 1001 ) || ( NODEID == 1002 ) ) &amp;&amp; ( GROUPID == 1000 ) )
{
 if( ( NODEID == 1000 ) || ( GROUPID != 1000 ) )
 {
  if( NODEID == 1001 )
  {
   exec 1.exe;
  }
  else
  {
   exec 2.exe;
  }
  exec a.exe;
 }
 else if( GROUPID == 1000 )
 {
  exec b.exe;
 }
}
else if( ( GROUPID != 1000 ) &amp;&amp; ( ( NODEID &gt; 2000 ) &amp;&amp; ( NODEID &lt; 2002 ) )
{
 exec c.exe;
}
else if( GROUPID != 1000 )
{
 exec d.exe;
}
else
{
 exec e.exe;
}

exec f.exe;
kill PROCESSID;



음.. 적고나니 실제로 이것보다는 약간 더 복잡했던듯.. ㅡ_ㅡ;;;
사실 예전부터 이런걸 한번 해보고 싶었는데, 이번에 새로 프로젝트를 진행하게되어 한번 해볼 수 있었다.

역시나 복잡하군.. ㅡ_ㅡ;;;
조 30줄도 안되는걸 처리할라고 내가 아는 모든 지식은 총동원되고, 아아 빡심...
나의 내공은 아직도 멀었나 보다.

쩝쩝.. 좀 한가해지면 x86Assembly나 빨리 완성해야 겠다.
그람 먼가 내공이 좀 올라가겠지. ㅋㅋㅋ

어제 드뎌 Assembly를 함 해보겠다고 assembly function을 만들어 Call을 했는데, 머 복잡한 루틴은 아니고, 그냥 간단히 word를 dword로 변환시켜 리턴하는 그런함수였다.

이걸 루프에서 주기적으로 call해서 clock을 측정해 보려는 용도였는데, 얼래...
굉장히 clock이 적게 나왔다. ㅡ_ㅡ;;;;

Sum 한 결과도 이상하고 그래서 따라가보니, 얼래.. for문의 Exit를 비교하는 부분이 이상했다. 분명 종료조건이 들어가있는 레지스터는 AC1인데, 비교하는건 T0와 비교하지 않는가?? ㅡ0ㅡ/~~

커헉... 내가 만든 Assembly function을 Call하지 않으면 멀쩡하고... 쩝쩝...초반부터 기선 제압을 당하는거 같다.
어디 두고보자 @0@/~~
앗쌀~~ 오늘 Assembly에 대해서 나와있는 책을 구했다.
ㅎㅎㅎ 이제 열심히 삽질하는 길만 남았군. @0@/~~
에궁.. 역시 세상에 쉬운일은 없는거 같다.
쿨럭..;;; ㅡ0ㅠ/~~
으읏... 젠장... 머리를 싸매고 문서를 뒤지고 쌩 쑈를 하면서 고민한 결과, 이미 되어있는 intrinsic 함수보다 더 빨리 하는 방법은 역시 Assembly로 승부하는수 밖에는 없는거 같다.

일단 머, MP3 Decoder는 실수 버퍼를 정수 버퍼로 교체하여 속도를 높이는 쪽으로 잠정적 결론이 났고, 앞으로의 작업을 위해 Assembly를 피해갈 수 없는 상황에 봉착해있다.

크윽... Assembly는 x86에서 커널 만들 때 말고는 안쓰리라 결심을 했건만... 안그래도 Assembly는 완전 쌩짜 수준인데... DSP꺼까지 봐야하다니... ㅡ0ㅠ/~~

절망이 아닐 수 없군....
쿨럭...;;;
오늘 DSP의 실수 처리 문제로 고민하다, 아는 사람의 회사에 인도 사람이 DSP를 하고 있다는 이야기를 들었다. 그사람은 DSP의 inline Assembly가 전문이란다. ㅡ0ㅡ...
홍냐... 당췌 DSP를 얼마나 해야 inline Assembly의 대가가될 수 있는 것인지...

난 겨우 x86소스를 포팅하는데도 진땀을 빼고있는데 말이다.
인도가 소프트웨어가 발달했다는 말을 들었는데, 머 이렇게나마 몸으로 느끼게 되네...

나도 외국인 친구나 사귀어 볼까나.. ㅡ_ㅡ;;;
DSP를 하는 인도 사람으로.. ㅋㅋㅋ

여튼 방심하지말고 열심히 해야겠다 @0@/~~
쿨럭.. 오늘 DSP의 실수연산이 정수연산보다 느리길래 단순히 실수 연산이 굉장히 느리다고 생각하고 있었다. 그런데... 오늘 같은 실수 연산을 ARM쪽에서 수행한 결과...

30배 정도 ARM이 클럭을 더 먹었다. @0@/~~ 쿨럭.. 이게 무슨일인지...
물론 ARM쪽에 하드웨어 가속 같은건 하나도 사용하고 있지 않았기때문에 정확한 테스트가 안되었을지는 모르겠지만 굉장한 클럭 소모였다.

음냥 그렇다면 DSP쪽에서의 실수연산은 나름대로 최적화된 Built in 함수를 이용해서 수행하고 있으니, 속도의 향상을 꾀할려면 얍삽 코드를 삽입하여 계산하는 수 밖에 없다는 것인데... 참으로 막막하다...

이를 어찌해야 좋을까나?? ㅡ0ㅠ/~~~
DSP 실수연산이 이렇게 클럭을 많이 잡아먹는줄 몰랐다.
DWORD 포인터의 덧셈연산이 9클럭을 잡아먹는데, 실수 걍 덧셈은 141클럭인가를 잡아먹는다.
이게 무슨일인가??
DSP는 실수연산용 칩이라고 알고있었던 나에게는 상당한 충격이 아닐 수 없다.
이실장님과 고민한끝에 일단 실수 연산을 클럭이 적게드는 정수연산으로 변환시키자는 방안이 나왔는데, 고민한 결과 다음과같이 나왔다.

첫번째는 소수점을 다 버리더라도 실수를 정수로 캐스팅한다음에 정수연산을 하는 방법이다. 이 방법은 1.9를 1로 만들어버리기 때문에 크게 좋은방법은 아닌듯 하다.

둘째는 내가 고정소수점 연산의 형식을 강제로 추출해서 가수는 가수끼리 지수는 지수끼리 더하는 방법이다. 이방법 역시 굉장히 빡시고 쉽게 되리라고 생각하지 않는다.

셋째는 가장 간단하고 쉬운 방법인데, 연산하는 실수 테이블 자체를 * 1000같은걸 해서 정수 테이블로 수정하고 나머지 연산들도 정수연산으로 바꾸는 것이다. 사실 MP3 디코더 역시 실수를 다시 정수로 변환하는 과정이 마지막에 있기때문에, 이방법을 이
용하면 마지막 과정은 / 1000 으로 간단히 해결할 수 있으므로 괜찮은 방법인거 같다.

일단 시도해 보도록하자.
홧팅이다 @0@/~~

 안녕하십니까 까마굽니다 (__)

 크윽... Add 명령을 조합하다가 도저히 지금의 구조로는 모든 명령에 대해 조합을맞추가기 어렵다는 결론이 났습니다.  MOV 까지는 잘 맞춰졌는데, Add가 되니까 약간씩 핀트가 어긋나서 다른 코드가 선택되는 걸 피할 수 가 없군요.

 으으... 이때까지 Register를 중심으로 Define하고 코드를 개발했었는데, 이게 오산이었습니다. 명령어의 Operand를 중심으로 했어야 하는데, 기존에 define 된걸 가지고 Operand를 맞출려고하니 무리가 있군요. Scanner 정도는 그냥 쓸수있을꺼 같은데, Parser랑 Code Generator는 완전히다시 써야 할듯 합니다.

 사실 생각한건데, Parser랑 Code Generator를 분리할 필요는 없다고 생각되네요. 분리를 하고 나니까 중복으로 검색하는것이 있어서, 하나로 합치는게 옳은거같군요. 일단 좌절입니다.

 아아.. 힘빠져.. ㅡ0ㅠ...다들 좋은하루 되세요 (__)

안녕하십니까 까마굽니다 (__)

삽질에 삽질을 거듭하다보니, 16bit와 32bit Asambler를 만들게... 머 그냥 Directive를 통해 전환이 가능한 형태이구요, 열심히 Intel의 테이블을보고 만들었습니다.

아직 LABEL에 대한 처리가 좀 미흡하고, mov 명령에 대한 구현 및 테스트를 하고있어서 다른 명령의 형식에는 어떻게 적용될지는 의문입니다만, 여튼 별반 수정없이처리할 수 있을꺼 같군요. 만들어 놓고도 참 신기합니다. 동작을 하긴 하는군요.

정말 이렇게 난잡한 프로그램은오래간만에 짜보는듯...Type Match를 위해 if-else switch의 난무.. ㅡ0ㅡ;;;;나중에 LABEL에 대한 마무리 처리를 조금 한다음, 소스코드를 좀더 간단하게 정리를해야 겠습니다. 아.. 오늘은 머리도 아프고 속도 영 않좋군요.병이 났나 봅니다 그려.. ㅋㅋㅋ그럼 다들 몸조심 하시고..

좋은하루 되세요 (__)

 안녕하십니까 까마굽니다 (__)
 으으.. 오늘 Machine Code Generator를 만들다가, OpCode까지는 어케 선택을 해줬는데, Mod 및 SIB를 선택하지 못하여 하루종일 보냈슴다. 이제야 필을 받아서 일단 mov reg, reg 형식을 대략 완성하고 output을 냈는데요,다행이도 nasm이랑 output이 같게 나오는걸 보니, 테이블을 틀리게 만든건 아닌거같군요.

 흠, 아직 테이블을 좀더 만들고 테스트해야 하는게 있긴하지만 머, 일단 첫발을내딛었기땜시롱 한자 끄적여 봅니다. 처음에는 모든 경우의 수를 생각하고 Scanner랑 Parser를 만들었는데요, 오늘 딱생각하니 빼먹은것이 있군요.

 으으, 다 포함하려니 소스가 자꾸 복잡해져서리 일단간단하게 완성하고 덧붙이던가 해야 되겠군요.에궁, 징짜 너무 빡시네요.

 그럼 좋은하루 되세요 (__)아래는 테스트 결과
/////////////////////////////////////////////////////////////////////////////
//input file
/////////////////////////////////////////////////////////////////////////////
mov ebx, eax
mov ebx, ecx
mov ebx, edx
mov ebx, esi
mov ebx, edi
mov ecx, eax
mov ecx, ebx
mov ecx, ecx
mov ecx, edx
mov ecx, esi
mov ecx, edi
mov edx, eax
mov edx, ebx
mov edx, ecx
mov edx, edx
mov edx, esi
mov edx, edi
mov esi, eax
mov esi, ebx
mov esi, ecx
mov esi, edx
mov esi, esi
mov esi, edi
mov edi, eax
mov edi, ebx
mov edi, ecx
mov edi, edx
mov edi, esi
mov edi, edi

//////////////////////////////////////////////////////////////////////////////
// 아래는 Kkamagui Simple Asambler Output
//////////////////////////////////////////////////////////////////////////////
Output[89C3]
Output[89CB]
Output[89D3]
Output[89F3]
Output[89FB]
Output[89C1]
Output[89D9]
Output[89C9]
Output[89D1]
Output[89F1]
Output[89F9]
Output[89C2]
Output[89DA]
Output[89CA]
Output[89D2]
Output[89F2]
Output[89FA]
Output[89C6]
Output[89DE]
Output[89CE]
Output[89D6]
Output[89F6]
Output[89FE]
Output[89C7]
Output[89DF]
Output[89CF]
Output[89D7]
Output[89F7]
Output[89FF]

 안녕하십니까 까마굽니다 (__)
 요 이틀째 어셈블러 제작에 매달리고 있는데요, 오늘 오전즈음해서 scanner를테스트한 다음, 그 output을 parser에 넣고 문법을 검사하려다보니, 기본적인 검사를 하더라도, 어셈명령에 따른 operand의 갯수 같은 것이 필요하겠더라구요.

 그리고 머신코드를 생성할 때는 각 operand에 따른 머신 코드의 맵핑 테이블이필요한데, 막상 고민해보니 깔끔한 생각이 안떠오르더군요. 하드코딩을 안할려고 머신코드의 규칙을 살펴봤으나, prefix/MOD/SIB 머 이런것들은 일정한 규칙같은게 있던데, 머신코드는.. ㅡ0ㅡ;;;;;

 그래서 nasm을 참고할려고 들여다 봤더니, 쿠.. 쿨럭...걍.. 테이블이 하드코딩 되어있더군요. ㅠㅇㅠ/~~크윽... 그래서 일단 저도 하드코딩해서 테이블을 만들어 놓고 이제 parser를만들어 테스트를 할려고 생각중입니다.하.. 참나... 이거 무쟈게 빡시군요.기본적으로 제가 쓰는 명령만 구현하는데도, 한참 걸리겠습니다. 그려...일단 오늘도 삽질 @0@/~~

 그럼 좋은하루 되세요 (__)

 안녕하십니까 까마굽니다 (__)
 넹 커널을 릴리즈한지 며칠이 지났는데요, 다행이도 "왜 일케 짯어요??" "정신이 있는 사람이에요??" 이런식의 글이 올라오지 않아서 긴장을 풀고 있습니다. ㅋㅋㅋ사실 잔뜩 요 며칠 쫄아있었기 땜시롱, 워낙 허접한 코드를 릴리즈해놔서 이것 또한걱정이군요.

 ㅡ0ㅡ;;;흠, 당분간 커널 소스는 손을 안대고, 다른걸 쪼금씩 해볼 생각을 하고 있습니다.머, 다음에 손보게 되면, FAT를 좀더 보강하고, 스레드를 구현해 넣고 GUI 함수약간 더 추가하는 정도가 될것 같군요.스레드와 GUI 함수에 대해서는 아직 뚜렷한 방향이 잡히지 않아서 약간 시간이 걸리겠구요, FAT 루틴은 사실 약간 보강이 된 상태인데 추가해야 할 부분이 생겨서그부분에 대한 처리를 미뤄둔 상태입니다.

 음, 글고보니 응용 프로그램용 라이브러리와 응용프로그램 전송하는 방법에 대한언급이 없었네요. 이것도 시간나는대로 릴리즈를... ㅋㅋㅋ아아, 눈탱이가 아프군요... 갑자기 왜이러지...그만 자야겠습니다.

 다들 좋은밤 되세요 (__)

 안녕하십니까 까마굽니다 (__)
 오늘 한번 어셈블러를 끄적거려 볼려고 했었습니다만, 쇼크만 먹었습니다.흠, 전 지금까지 Opcode는 각 명령에 대해서 1:1로 대응되는줄 알고있었기때문에,쉽게 보고 있었는데, 오늘 문서를 보니 같은 mov라도 뒤의 Operand에 따라서 Opcode가 틀리더군요.

 또 뒤에 오는 Operand 타입에 따라서 옵션으로 설정되는 것들이 있고, 으아~~ 어찌나 복잡하던지...하는수 없이, 책을 일단 쬐금 복사한다음 nasm을 이용해서 역어셈해가면서 봤습니다.규칙이 있긴하던데, 머 관건은 머신코드를 작성할때 적절한 Opcode를 선택하기위해서는 Operand의 Type을 알고있어야 한다는 결론에 봉착한것 말고는 별 소득이 없네요.테이블도 몇개를 이용해야 될꺼 같고, 으음 일단 mov 명령을 잘 뜯어본다음 nasm과동일한 output이 나오도록 한번 해봐야 겠습니다.

 그러려고하니 문제가, scanner를 만들어야 하겠는데 머 만드는거야 별 문제가 없지만 중요한건 scanner의 output을 parser가 가지고가서 문법 체크를 하고, 다시 이걸넘겨받아서 머신코드를 만드는 놈이 output을 만들어 내야 하는데, scanner의 output을 어떤식으로 할지가 문제군요.머 일단 Token단위로 자른다 치면, scanner의 output으로는 Token별 String도 있어야 할터인데 어떤식으로 할지 걱정이군요.걍 Queue에 넣어버릴까나, 쩝쩝... 암생각하지말고 String의 크기만큼 동적할당해서걍 스트링 복사한다음 Queue에 넣는 무식한 방법도 생각하고 있습니다.

 오홀홀홀.. 혹시 머 좋은 생각 있으신분 계신가요??있으시면 답글좀...
 그럼 좋은하루 되세요 (__)

+ Recent posts