ICC AVR и стpоки

Hello Dmitry.

24 Sep 03 19:00, you wrote to me:
ë ÓÏÖÁÌÅÎÉÀ, Ñ ÎÅ ÏÞÅÎØ × ËÕÒÓÅ. HÏ ÎÁÓËÏÌØËÏ Ñ ÐÏÎÑÌ, ÄÏÓÔÁÔÏÞÎÏ ÂÙÌÏ × ÌÉÎËÅÒÎÙÊ ÓËÒÉÐÔ ÄÏÂÁ×ÉÔØ ÓÅËÃÉÉ .ctors .dtors

DF> ÷Ï 1-È, ÜÔÏ ÚÁ×ÉÓÉÔ ÏÔ ÃÅÌÅ×ÏÊ ÐÌÁÔÆÏÒÍÙ, DF> ×Ï 2-È, ÈÏÔØ Ñ É ÐÒÏ×ÏÖÕ ÁÎÁÌÏÇÉÀ ÍÅÖÄÕ ÐÏÄÄÅÒÖËÏÊ C++ ÄÌÑ DF> ÍÏÄÕÌÅÊ ÑÄÒÁ ÌÉÎÕËÓ É ÎÁÓÔÏÑÝÅÊ ×ÄÅÌÁÎÎÏÊ ÐÌÁÔÆÏÒÍÏÊ, ÏÎÉ ×ÓÅ-ÔÁËÉ DF> ÏÔÌÉÞÁÀÔÓÑ. × 3-È, × ÏÔÌÉÞÉÅ ÏÔ g++, × ÓÌÕÞÁÅ ÑÄÒÁ ÌÉÎÕËÓ, ÎÕÖÎÏ DF> ÐÒÉÌÁÇÁÔØ ÎÅÍÁÌÏ ÕÓÉÌÉÊ ÄÌÑ ÏÂÈÏÄÁ ÏÇÒÁÎÉÞÅÎÉÊ ÜÔÏÊ ÓÒÅÄÙ, DF> ÉÓÐÏÌØÚÏ×ÁÎÉÀ C++ ÁËÔÉ×ÎÏ ÓÏÐÒÏÔÉ×ÌÑÀÝÅÊÓÑ, Á ÐÏÔÏÍÕ ÔÁÍ ÏËÏÌÏ DF> ÐÏÌÏ×ÉÎÙ ÏÂßÅÍÁ ÉÓÈÏÄÎÉËÏ× ÚÁÎÉÍÁÀÔ ×ÓÑËÉÅ ÍÁËÒÏÓÙ É ÕÓÌÏ×ÉÑ.

÷ÏÔ ×ÏÔ. ðÒÉÍÅÒ ÎÅÕÄÁÞÎÙÊ.

Alexey

Reply to
Alexey Boyko
Loading thread data ...

Hello "Harry.

24 Sep 03 20:59, you wrote to Oleksandr Redchuk:

HZ>>> á ËÁË ÔÏÇÄÁ ÂÙÔØ Ó ÐÒÅÒÙ×ÁÎÉÑÍÉ? ô.Å. ×ÏÔ ×ÏÛÌÉ × ÆÕÎËÃÉÀ, HZ>>> ÓËÏÐÉÒÏ×ÁÌÉ SP × Y, ÎÁÞÁÌÉ ÉÓÐÏÌØÚÏ×ÁÔØ Y, É ÔÕÔ - ÂÁÃ! - HZ>>> ÐÒÅÒÙ×ÁÎÉÅ! ëÁËÏÊ ÐÏÉÎÔÅÒ ÂÕÄÅÔ ÉÓÐÏÌØÚÏ×ÁÔØÓÑ × ÐÒÅÒÙ×ÁÎÉÉ? OR>> åÓÌÉ ÐÒÅÒÙ×ÁÎÉÀ ÎÁÄÏ, ÔÏ ÏÎÏ ÓÅÂÅ ÓÄÅÌÁÅÔ, ÅÓÌÉ ÎÅ ÎÁÄÏ - ÄÅÌÁÔØ OR>> ÎÅ ÂÕÄÅÔ. HÅ ÐÏÎÉÍÁÀ, × ?Í ÐÒÏÂÌÅÍÙ, ÞÔÏ ÔÅÂÅ ÎÅÐÏÎÑÔÎÏ.

HZ> íÎÅ ÎÅ ÐÏÎÑÔÎÏ ×ÏÔ ÞÔÏ: ÚÁÛÌÉ × ÆÕÎËÃÉÀ, ÓËÏÐÉÒÏ×ÁÌÉ SP × Y, HZ> ÎÁÞÁÌÉ Ó ÎÉÍ ÒÁÂÏÔÁÔØ - ÒÁÚÍÅÓÔÉÌÉ × ÜÔÏÊ ÐÁÍÑÔÉ ÌÏËÁÌØÎÙÅ ÏÂßÅËÔÙ, Y, HZ> ÅÓÓÎÏ, ÍÏÄÉÆÉÃÉÒÏ×ÁÌÓÑ - TOS "ÕÐÌÙÌ" ÏÔ ÉÓÈÏÄÎÏÇÏ ÚÎÁÞÅÎÉÑ SP ÎÁ HZ> ×ÅÌÉÞÉÎÕ ÒÁÚÍÅÒÁ ÌÏËÁÌØÎÙÈ ÏÂßÅËÔÏ× + ÍÅÓÔÏ ÐÏÄ ÁÄÒÅÓ ×ÏÚ×ÒÁÔÁ ÎÁ HZ> ÓÌÕÞÁÊ ÐÒÅÒÙ×ÁÎÉÑ/×ÙÚÏ× ÆÕÎËÃÉÉ.

HÅÔ. SP ÔÁËÖÅ ÏÐÕÓËÁÅÔÓÑ ×ÎÉÚ.

push bp mov bp, sp sub sp, locals

ðÏÍÎÉÛØ ÔÁËÏÅ? ôÁË ×ÏÔ ÜÔÏÔ ÓÁÍÙÊ sub sp, locals ÎÁ AVR ÎÕ ÏÞÅÎØ ÐÌÏÈÏ ÐÏÌÕÞÁÅÔÓÑ.

Alexey

Reply to
Alexey Boyko

Thu Sep 25 2003 12:51, Alexey Musin wrote to Vladimir Vassilevsky:

VV>> äÁ ÄÁÖÅ ÍÅÎÀÛÎÙÊ ××ÏÄ/×Ù×ÏÄ ÎÁ Ä×ÕÈÓÔÒÏÞÎÉË ÕÄÏÂÎÅÅ ÐÉÓÁÔØ ÎÁ ++. AM> ÔÙ ÐpÏ pÅÁÌÉÚÁÃÉÀ ÉÌÉ ÉÓÐÏÌØÚÏ×ÁÎÉÅ?

ìÅÇËÏ ÒÅÁÌÉÚÏ×Ù×ÁÔØ, ÉÓÐÏÌØÚÏ×ÁÔØ É ×ÎÏÓÉÔØ ÉÚÍÅÎÅÎÉÑ.

AM> ðpÏ pÅÁÌÉÚÁÃÉÀ

AM> ÄÅpÅ×Ï ÍÅÎÀ pÅÁÌÉÚyÅÔÓÑ Ó×ÑÚÎÙÍ ÓÐÉÓËÏÍ, ÐpÉÞÅÍ ÔyÔ ó/ó++/ÌÀÂÏÊ ÄpyÇÏÊ AM> ÑÚÙË ?

óÏ×ÅÒÛÅÎÎÏ ÎÅÏÂÑÚÁÔÅÌØÎÏ. óÐÏÓÏÂÏ× ÍÎÏÇÏ: × ÌÏÂ, ÞÅÒÅÚ ÍÁÛÉÎÕ ÓÏÓÔÏÑÎÉÊ, ÓÏÂÙÔÉÊÎÏ ÕÐÒÁ×ÌÑÅÍÏÅ ÉÌÉ ÆÕÎËÃÉÏÎÁÌØÎÏ ÕÐÒÁ×ÌÑÅÍÏÅ, c/ÂÅÚ ÍÎÏÇÏÚÁÄÁÞÎÏÓÔØÀ É ÐÒ.

AM> ðpÏ ÉÓÐÏÌØÚÏ×ÁÎÉÅ

AM> ÅÓÔØ ÎÁÂÏp ÍÏÄyÌÅÊ, ËÏÔÏpÙÍ Ñ ÐÏÌØÚyÀÓØ ÄÌÑ ×Ù×ÏÄÁ ÎÁ ÜËpÁÎ 16È4 öëé AM> (ÎÁ ÓÁÍÏÍ ÄÅÌÅ ÉÎÆÁ ÐÏÓÙÌÁÅÔÓÑ ÞÅpÅÚ CAN × ÍÏÄyÌØ, Ë ËÏÔÏpÏÍy ÐÏÄËÌÀÞÅÎ AM> öëé)

AM> === Begin Windows Clipboard === AM> /* ÓÔÉÒÁÅÍ ÄÉÓÐÌÅÊ É ×Ù×ÏÄÉÍ ÓÔÁÔÉÞÅÓËÕÀ ÉÎÆÏÒÍÁÃÉÀ ÎÁ ÄÉÓÐÌÅÊ */ AM> SsScrPutStr (" ÷ÅÒÓÉÑ ðï", 0, SCR_CONST_STR_FLG | AM> SCR_DISP_CLR_FLG); AM> SsScrPutStr (" "VERSION_STR, 0, SCR_POS_L2 | SCR_POS_P1 | AM> SCR_CONST_STR_FLG); === End Windows Clipboard ===

ôÏ ÅÓÔØ × ÌÏÂ. äÏÂÁ×ÉÔØ/ÕÂÁ×ÉÔØ/ÉÚÍÅÎÉÔØ ÐÒÉ ÜÔÏÍ ÐÏÄÈÏÄÅ ÞÔÏ-ÔÏ ÓÌÏÖÎÏ.

menu = new MENU(RESOURCE, enter); ×ÓÅ ÍÅÎÀ ÏÐÉÓÁÎÏ ËÁË ÒÅÓÕÒÓ - É ËÕÄÁ ÏÎÏ ×ÈÏÄÉÔ, É ËÕÄÁ ÏÎÏ ×ÙÈÏÄÉÔ, É ÞÔÏ É ËÁË ××ÏÄÉÔÓÑ.

AM> çÌÁ×ÎÏÅ ÐpÏÂÌÅÍÁ × ++ ÄÌÑ ÍÅÎÑ - ÎÁÄÏ _ÐÏ-ÄpyÇÏÍy_ ÐpÏÅËÔÉpÏ×ÁÔØ.

ðÒÏÓÔÏ ÄÅÌÏ ÐÒÉ×ÙÞËÉ É ×ËÕÓÁ.

VLV

Reply to
Vladimir Vassilevsky

Hello Oleksandr.

25 Sep 03 09:11, you wrote to "Harry Zhurov": óÐÒÁ×ÅÄÌÉ×ÏÓÔÉ ÒÁÄÉ ÈÏÞÕ ÚÁÍÅÔÉÔØ:

OR> ä×Á ÓÔÅËÁ (ÄÁÎÎÙÈ É ÕÐÒÁ×ÌÅÎÉÑ) -- ÍÙÓÌØ ÄÏ×ÏÌØÎÏ ÎÅÐÌÏÈÁÑ. OR> HÏ, Ó ÄÒÕÇÏÊ ÓÔÏÒÏÎÙ, ÔÒÅÂÕÀÝÁÑ ÂÏÌÅÅ ÁËËÕÒÁÔÎÏÇÏ ÒÁÓÐÒÅÄÅÌÅÎÉÑ OR> ÐÁÍÑÔÉ -- ËÁÖÄÏÍÕ ÓÔÅËÕ ÎÁÄÏ ÄÁÔØ, É ËÁÖÄÏÍÕ ÞÔÏÂÙ È×ÁÔÉÌÏ. OR> ó ÔÒÅÔØÅÊ - ÎÅÕÖÅÌÉ ÎÅÔ gcc ÄÌÑ sparc?

åÓÔØ.

OR> á Õ ÎÅÇÏ, ÅÓÌÉ Ñ ÐÒÁ×ÉÌØÎÏ ÐÏÍÎÀ, ÓÒÁÚÕ ÐÏ ÖÉÚÎÉ Ä×Á ÕËÁÚÁÔÅÌÑ ÓÔÅËÁ.

óÔÅËÁ 2, ÕËÁÚÁÔÅÌØ ÏÄÉÎ :) ôÏÞÎÅÅ ÏÄÉÎ ÓÔÅË ÁÐÐÁÒÁÔÎÙÊ - ÒÅÇÉÓÔÒÏ×ÙÅ ÏËÎÁ. HÁ ÎÅÍ ÓÏÈÒÁÎÑÀÔÓÑ ÁÄÒÅÓÁ ×ÏÚ×ÒÁÔÏ×, ÐÅÒ×ÙÅ 6 ÐÁÒÁÍÅÔÒÏ× ÐÒÏÃÅÄÕÒÙ, ÌÏËÁÌÙ ÐÒÏÃÅÄÕÒÙ É ÕËÁÚÁÔÅÌÉ ÄÌÑ 2ÇÏ ÓÔÅËÁ (sp É fp). üÔÏÔ ÓÔÅË ÐÏÌÎÏÓÔØÀ ÏÂÓÌÕÖÉ×ÁÅÔÓÑ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ. ÷ÔÏÒÏÊ ÓÔÅË ÒÁÓÐÏÌÏÖÅÎ × ÐÁÍÑÔÉ É ÕÐÒÁ×ÌÑÅÔÓÑ ÐÒÏÇÒÁÍÍÏÊ. ÷ ÎÅÍ ÈÒÁÎÑÔÓÑ ×ÓÅ ÐÁÒÁÍÅÔÒÙ (ÐÏÄ ÐÅÒ×ÙÅ 6 ÔÏÌØËÏ ÏÔ×ÅÄÅÎÏ ÍÅÓÔÏ), ÌÏËÁÌØÎÙÅ É ×ÒÅÍÅÎÎÙÅ ÐÅÒÅÍÅÎÎÙÅ, ËÏÔÏÒÙÅ ÎÅ ÕÍÅÓÔÉÌÉÓØ × ÒÅÇÉÓÔÒÙ, ÅÝÅ ÔÁÍ ÅÓÔØ ÏÂÌÁÓÔØ ÄÌÑ ÓÏÈÒÁÎÅÎÉÑ ÔÅËÕÝÅÇÏ ÏËÎÁ ÒÅÇÉÓÔÒÏ× (ÉÚ 1ÇÏ ÓÔÅËÁ). üÔÏÔ ÓÔÅË ÔÁË ÖÅ ÉÓÐÏÌØÚÕÅÔÓÑ ÏÐÅÒÁÃÉÏÎÎÏÊ ÓÉÓÔÅÍÏÊ (ÄÌÑ ÓÏÈÒÁÎÅÎÉÑ ÒÅÇÉÓÔÒÏ×). óÏÚÄÁÎÉÅ/ÕÄÁÌÅÎÉÅ ÆÒÅÊÍÏ× ÎÁ ÏÂÏÉÈ ÓÔÅËÁÈ ÐÒÏÉÚ×ÏÄÉÔÓÑ ÏÄÎÏÊ ËÏÍÁÎÄÏÊ (ÏÄÎÁ ÄÌÑ ÓÏÚÄÁÎÉÑ, ×ÔÏÒÁÑ ÄÌÑ ÕÄÁÌÅÎÉÑ)

Roman

Reply to
Roman Khvatov

Oleksandr Redchuk wrote to "Harry Zhurov" on Thu, 25 Sep 2003 05:11:46 +0000 (UTC):

OR>>> îÅ ÐÏÎÉÍÁÀ, × ?Í ÐÒÏÂÌÅÍÙ, ÞÔÏ ÔÅÂÅ ÎÅÐÏÎÑÔÎÏ.

HZ>> íÎÅ ÎÅ ÐÏÎÑÔÎÏ ×ÏÔ ÞÔÏ: ÚÁÛÌÉ × ÆÕÎËÃÉÀ, ÓËÏÐÉÒÏ×ÁÌÉ SP × Y, OR> ×ÙÞÌÉ ÉÚ SP ÒÁÚÍÅÒ ÌÏËÁÌØÎÙÈ ÐÅÒÅÍÅÎÎÙÈ

÷ÓÅ ÜÔÏ × ËÒÉÔÉÞÅÓËÏÊ ÓÅËÃÉÉ?

HZ>> ÎÁÞÁÌÉ Ó ÎÉÍ ÒÁÂÏÔÁÔØ -

sbiw r28:r29,... ; ×ÙÄÅÌÉÌÉ ÐÁÍÑÔØ ÐÏÄ ÎÅÓËÏÌØËÏ ÐÅÒÅÍÅÎÎÙÈ

st -Y,... ; ÔÕÔ ÓÕÎÕÌÉ × ÓÔÅË ÅÝÅ ÐÅÒÅÍÅÎÎÕÀ ...

st -Y,... ; ÔÕÔ ÅÝÅ ... ...

st -Y,... ; É ÔÕÔ ...

üÔÏ ÞÔÏ, ÐÏÓÌÅ ËÁÖÄÏÇÏ ÔÁËÏÇÏ ÏÂÒÁÝÅÎÉÑ SP ÍÏÄÉÆÉÃÉÒÏ×ÁÔØ? ô.Å. ÏÂÁ ÕËÁÚÁÔÅÌÑ ÍÏÄÉÆÉÃÉÒÏ×ÁÔØ ÓÉÎÈÒÏÎÎÏ? äÁ ÅÝÅ É ÐÒÉÄÅÔÓÑ × ËÒÉÔÉÞÅÓËÕÀ ÓÅËÃÉÀ ÚÁËÌÀÞÁÔØ ÌÀÂÏÅ ÔÁËÏÅ ÉÚÍÅÎÅÎÉÅ, ÄÁÂÙ ÁÔÏÍÁÒÎÏÓÔØ ÎÅ ÐÏÔÅÒÑÔØ? îÏ ÔÏÇÄÁ ËÁËÏÊ ÓÍÙÓÌ × ÜÔÏÍ Y × ËÁÞÅÓÔ×Å ÕËÁÚÁÔÅÌÑ ÓÔÅËÁ, ËÏÇÄÁ ÔÁËÏÊ Ï×ÅÒÈÅÄ? éÌÉ ÓÒÁÚÕ ×ÙÄÅÌÑÔØ ÐÏ ÍÁËÓÉÍÕÍÕ, ÓËÏÌØËÏ × ÆÕÎËÃÉÉ ÎÕÖÎÏ? é ÎÅ ÐÏÌØÚÏ×ÁÔØÓÑ st -Y,..., Á ×ÍÅÓÔÏ ÎÅÅ std Y+n,...? îÁ×ÅÒÎÏÅ, ÜÔÏ ×ÁÒÉÁÎÔ. îÏ ×ÓÅ ÒÁ×ÎÏ ÎÅÈÏÒÏÛÏ. äÕÒÁÃÉÊ ÔÁÍ SP! [...]

HZ>> Y, É ÐÏ ÔÏÊ ÖÅ ÓÈÅÍÅ ÉÓÐÏÌØÚÕÅÔÓÑ ÐÁÍÑÔØ ÓÔÅËÁ. îÏ ÜÔÏ ÔÁ ÖÅ ÓÁÍÁÑ HZ>> ÐÁÍÑÔØ, ËÏÔÏÒÁÑ ÕÖÅ ÉÓÐÏÌØÚÕÅÔÓÑ × ÐÒÅÒ×ÁÎÎÏÊ ÆÕÎËÃÉÉ!? OR> ôÙ ÞÔÏ, Å? ÎÅ ÒÁÚÂÉÒÁÌÓÑ ËÁË ÜÔÏ ÓÄÅÌÁÎÏ Õ MSP Ó ÏÄÎÉÍ ÓÔÅËÏÍ?

ðÒÉÞÅÍ ÔÕÔ 430-Ê? õ ÎÅÇÏ SP ÎÏÒÍÁÌØÎÏ ÓÄÅÌÁÎ, ÏÎ ÐÏÚ×ÏÌÑÅÔ ÁÄÒÅÓÏ×ÁÔØÓÑ ÌÀÂÙÍ ÛÔÁÔÎÙÍ ÓÐÏÓÏÂÏÍ É ËÏÓ×ÅÎÎÏ, É ÓÏ ÓÍÅÝÅÎÉÅÍ, É ÁÄÒÅÓÎÁÑ ÁÒÉÆÍÅÔÉËÁ ÔÁÍ ÒÁÂÏÔÁÅÔ, ÐÏÜÔÏÍÕ ÎÅÔ ÎÅÏÂÈÏÄÉÍÏÓÔÉ ÅÇÏ ÚÎÁÞÅÎÉÅ ËÕÄÁ-ÔÏ ËÏÐÉÒÏ×ÁÔØ. ÷ÏÔ ÅÓÌÉ ÂÙ × ÔÏÍ ÖÅ AVR Y-pointer ÂÙÌ ÂÙ ÏÄÎÏ×ÒÅÍÅÎÎÏ É SP (Ô.Å. ÂÙÌ ÂÙ ÓÐÏÓÏÂÅÎ ÕÞÁÓÔ×Ï×ÁÔØ × ÐÒÏÃÅÓÓÅ ÚÁÐÏÍÉÎÁÎÉÑ ÁÄÒÅÓÏ× ×ÏÚ×ÒÁÔÏ× ÉÚ ÆÕÎËÃÉÊ É ÐÒÅÒÙ×ÁÎÉÊ), ÔÏ ×ÓÅÇÏ ÜÔÏÇÏ ÇÅÍÏÒÒÏÑ ÎÅ ÂÙÌÏ ÂÙ. ðÒÁ×ÄÁ ÔÏÇÄÁ ÔÁÍ ÏÓÔÁÌÏÓØ ÂÙ ÐÏÌÔÏÒÁ ÕËÁÚÁÔÅÌÑ. [...]

HZ>> ÷ÏÔ ÅÓÌÉ ÉÓÐÏÌØÚÏ×ÁÔØ HZ>> ÄÌÑ ÐÒÅÒÙ×ÁÎÉÊ ÏÔÄÅÌØÎÙÊ ÓÔÅË, ÔÏ ÔÏÇÄÁ, ×ÒÏÄÅ, ÄÏÌÖÎÏ ÐÏÌÕÞÉÔØÓÑ. OR> ä×Á ÓÔÅËÁ (ÄÁÎÎÙÈ É ÕÐÒÁ×ÌÅÎÉÑ) -- ÍÙÓÌØ ÄÏ×ÏÌØÎÏ ÎÅÐÌÏÈÁÑ.

á ÜÔÏ × ïó ÉÓÐÏÌØÚÕÅÔÓÑ - ÔÁÍ ÚÁÞÁÓÔÕÀ ÕÄÁÞÎÙÍ Ñ×ÌÑÅÔÓÑ ÒÅÛÅÎÉÅ, ËÏÇÄÁ ÄÌÑ ÐÒÅÒÙ×ÁÎÉÊ Ó×ÏÊ ÓÔÅË. é ÔÕÔ ÂÙ ÜÔÏ ÍÏÇÌÏ ÒÅÛÉÔØ ÐÒÏÂÌÅÍÕ ÓÏ ÓÔÅËÏ×ÙÍ ËÁÄÒÏÍ.

OR> îÏ, Ó ÄÒÕÇÏÊ ÓÔÏÒÏÎÙ, ÔÒÅÂÕÀÝÁÑ ÂÏÌÅÅ ÁËËÕÒÁÔÎÏÇÏ ÒÁÓÐÒÅÄÅÌÅÎÉÑ OR> ÐÁÍÑÔÉ -- ËÁÖÄÏÍÕ ÓÔÅËÕ ÎÁÄÏ ÄÁÔØ, É ËÁÖÄÏÍÕ ÞÔÏÂÙ È×ÁÔÉÌÏ.

ôÁË ×ÅÄØ Õ éáòÏ× Ä×Á ÓÔÅËÁ, ÐÒÁ×ÄÁ ÏÎÉ ÎÅ ÔÁËÉÅ, ÎÏ ÔÏÖÅ ÎÕÖÎÏ ÚÁ ÜÔÉÍ ÓÌÅÄÉÔØ.

...so long!

### ëÏÇÄÁ ÍÁÌÏ ×ÒÅÍÅÎÉ, ÔÕÔ ÕÖÅ ÎÅ ÄÏ ÄÒÕÖÂÙ - ÔÏÌØËÏ ÌÀÂÏ×Ø.

Reply to
Harry Zhurov

Oleksandr Redchuk wrote to "Harry Zhurov" on Thu, 25 Sep 2003 05:39:15 +0000 (UTC):

AB>>> ðÏ×ÅÚÌÏ ÍÎÅ. á ÞÔÏ × éáò ó ÎÅÔÕ inline?

HZ>> ÷ éáò, ËÁË É ÐÏÌÏÖÅÎÏ ÓÉÛÎÏÍÕ ËÏÍÐÉÌÑÔÏÒÕ, ×ÓÔÒÁÉ×ÁÅÍÙÈ ÆÕÎËÃÉÊ ÎÅÔ.

OR> ëÏÍÐÉÌÑÔÏÒÕ, ÓÏÏÔ×ÅÔÓÔ×ÕÀÝÅÍÕ

OR> INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:1999 OR> Programming languages - C

OR> inline ÉÍÅÔØ ÐÏÌÏÖÅÎÏ. õÖÅ 3 ÇÏÄÁ ËÁË.

IAR C - ÐÏÓÌÅÄÎÑÑ ×ÅÒÓÉÑ, afaik, 1.51, ×ÙÛÌÁ ÇÄÅ-ÔÏ × 99 ÇÏÄÕ. é ÍÎÏÇÏ ÔÙ ÚÎÁÅÛØ ËÏÍÐÉÌÑÔÏÒÏ×, ÕÄÏ×ÌÅÔ×ÏÒÑÀÝÉÈ C99? ôÁÍ, ËÓÔÁÔÉ, ÅÓÌÉ É ÂÏÌÅÅ ÓÕÝÅÓÔ×ÅÎÎÙÅ ×ÅÝÉ - ÌÏËÁÌØÎÙÅ ÄÉÎÁÍÉÞÅÓËÉÅ ÍÁÓÓÉ×Ù. ëÁËÉÅ ËÏÍÐÉÌÑÔÏÒÙ ÕÖÅ ÐÏÄÄÅÒÖÉ×ÁÀÔ ÜÔÏ?

...so long!

### úÁÐÌÁÔÉÌ ÎÁÌÏÇÉ É ÓÐÌÀ ÓÐÏËÏÊÎÏ. îÁ ÌÁ×ÏÞËÁÈ, × ÐÏÄ×ÁÌÁÈ, ÎÁ ×ÏËÚÁÌÅ.

Reply to
Harry Zhurov

Alexey Musin wrote to Harry Zhurov on Thu, 25 Sep 2003 11:48:10 +0400:

HZ>>>> ô.Å. ÓÄÅÌÁÔØ ÉÍÅÎÎÏ ÔÏ, ÞÔÏ ÎÁ ++ ÐÏÌÕÞÁÅÔÓÑ ÎÁÔÉ×ÎÏ. é ÐÏÓÌÅ HZ>>>> ÜÔÏÇÏ ÅÝÅ ÎÅ ÓÞÉÔÁÔØ ++ÎÕÀ ÍÏÄÅÌØ ÌÕÞÛÅÊ, ÞÅÍ ÓÉÛÎÕÀ! OR>>> é ÎÅÏÂÈÏÄÉÍÏÓÔØ ÐÉÓÁÔØ × ËÌÁÓÓÁÈ ÓÌÏ×Á private - ÜÔÏ OR>>> ÔÏ, ÞÔÏ ÎÁ ÁÓÓÅÍÂÌÅÒÅ ÐÏÌÕÞÁÅÔÓÑ ÎÁÔÉ×ÎÏ. HZ>> ÷ ËÌÁÓÓÁÈ ÐÉÓÁÔØ private ÎÅ ÎÁÄÏ - ÏÂßÑ×ÌÑÅÛØ ÐÒÉ×ÁÔÎÏÅ ÓÒÁÚÕ, ÐÏÔÏÍ HZ>> ÐÉÛÅÛØ public ÄÌÑ ÏÔËÒÙÔÏÇÏ É ×ÕÁÌÑ. :) ô.Þ. ×ÓÅ ÎÁÔÉ×ÎÏ. :))

AM> ÔÅÍÎÉÛØ :) AM> ÈÏpÏÛÉÊ ÓÔÉÌØ ××ÅpÈy pÁÚÍÅÓÔÉÔØ public, Á ÎÉÖÅ ÎÅÇÏ - private

üÔÏ Ó ÞÅÇÏ ÔÙ ×ÚÑÌ? üÔÏÔ ÓÔÉÌØ Õ ×ÓÅÈ Ó×ÏÊ, É ÍÏÖÎÏ ÄÏÌÇÏ ÓÐÏÒÉÔØ, ËÁËÏÊ ÌÕÞÛÅ É ÐÒÁ×ÉÌØÎÅÅ.

...so long!

### "äÏÑÒËÁ ÓÏÛÌÁ Ó ÔÒÉÂÕÎÙ, É ÎÁ ÎÅe ÔÏÔÞÁÓ ÖÅ ×ÌÅÚ ÐÒÅÄÓÅÄÁÔÅÌØ." (Ó) éÚ ÛËÏÌØÎÏÇÏ ÓÏÞÉÎÅÎÉÑ.

Reply to
Harry Zhurov

Hi Harry, hope you are having a nice day!

25 óÅÎ 03, Harry Zhurov wrote to Alexey Musin:

HZ>>> ÷ ËÌÁÓÓÁÈ ÐÉÓÁÔØ private ÎÅ ÎÁÄÏ - ÏÂßÑ×ÌÑÅÛØ ÐÒÉ×ÁÔÎÏÅ HZ>>> ÓÒÁÚÕ, ÐÏÔÏÍ ÐÉÛÅÛØ public ÄÌÑ ÏÔËÒÙÔÏÇÏ É ×ÕÁÌÑ. :) ô.Þ. ×ÓÅ HZ>>> ÎÁÔÉ×ÎÏ. :))

AM>> ÔÅÍÎÉÛØ :) AM>> ÈÏpÏÛÉÊ ÓÔÉÌØ ××ÅpÈy pÁÚÍÅÓÔÉÔØ public, Á ÎÉÖÅ ÎÅÇÏ - private

HZ> üÔÏ Ó ÞÅÇÏ ÔÙ ×ÚÑÌ? üÔÏÔ ÓÔÉÌØ Õ ×ÓÅÈ Ó×ÏÊ, É ÍÏÖÎÏ ÄÏÌÇÏ ÓÐÏÒÉÔØ, HZ> ËÁËÏÊ ÌÕÞÛÅ É ÐÒÁ×ÉÌØÎÅÅ.

óÔÒÁÕÓÔÒÕÐ ÓÞÉÔÁÅÔ ÉÎÁÞÅ. åÍÕ ÎÅÌØÚÑ ×ÅÒÉÔØ? :)

WBR, AVB

ICQ# 43835774 mailto: avbdialup.etr.ru

Reply to
Alexey V Bugrov

Hello "Harry.

25 Sep 03 19:22, you wrote to Oleksandr Redchuk:

OR>> inline иметь положено. Уже 3 года как. HZ> IAR C - последняя версия, afaik, 1.51, вышла где-то в 99 году. И HZ> много ты знаешь компиляторов, удовлетворяющих C99? Там, кстати, если и HZ> более существенные вещи - локальные динамические массивы. Какие HZ> компиляторы уже поддерживают это?

gcc

Я даже пользовался.

Alexey

Reply to
Alexey Boyko

Hello "Harry.

25 Sep 03 19:22, you wrote to Oleksandr Redchuk:

OR>> вычли из SP размер локальных переменных HZ> Все это в критической секции?

У тебя же есть avr-gcc. Посмотри же сам.

HZ>>> начали с ним работать -

HZ> sbiw r28:r29,... ; выделили память под несколько переменных

; аналогично push BP push R28 push R29

; аналогично mov BP, SP in R28, SPL in R29, SPH

; аналогично sub SP, locals sbiw R28, locals in tmp, SREG cli out SPH, R29 out SREG, tmp out SPL, R28

Теперь SP продолжает указывать на вершину стека, а Y - на кадр стека Стек то один.

HZ> st -Y,... ; тут сунули в стек еще переменную HZ> ...

Зачем? Переменные и так в распределены в стеке. Если нужно сохранить что-то, то push/pop

HZ> Это что, после каждого такого обращения SP модифицировать?

Теперь понял?

Если компилировать с опцией -mno-interrupt, тогда при сохранении SP, нет шаманства с SREG, а просто

out SPL, R28 out SPH, R29

А был бы SP регистром, то вообще:

push R28 push R29 sbiw R28, locals movw SP, R28

HZ> Причем тут 430-й? У него SP нормально сделан, он позволяет HZ> адресоваться любым штатным способом и косвенно, и со смещением, и HZ> адресная арифметика там работает, поэтому нет необходимости его HZ> значение куда-то копировать. Вот если бы в том же AVR Y-pointer был бы HZ> одновременно и SP (т.е. был бы способен участвовать в процессе HZ> запоминания адресов возвратов из функций и прерываний), то всего этого HZ> геморроя не было бы. Правда тогда там осталось бы полтора указателя.

Можно было убрать in/out, а вместо них сделать 4 регистровых пары указателя.

r24:r25, r26:r27, r28:r29, r30:r31

Это было бы намного лучше.

А еще можно было убрать половину регистров, так как только половина из них нормальные, а остальные используются только как временное хранение.

Alexey

Reply to
Alexey Boyko

Alexey Boyko wrote to "Harry Zhurov" <Harry Zhurov on Thu, 25 Sep 2003 12:46:42

+0400:

AB>>> Вообще-то я спрашивал почему не пройдет. HZ>> Потому что, например, если есть объявленный пользователем HZ>> копирующий оператор присваивания, то этот оператор подразумевает HZ>> определенную семантику HZ>> копирования, а простое побитовое копирование имеет вполне определенную HZ>> семантику клонирования, что позволяет создавать объекты неразрешенным HZ>> способом. Или если есть приватные поля, то доступ к ним должен быть HZ>> только через определенный интерфейс, и если просто побитово HZ>> копировать, то это значит получить к ним доступ в обход системы типов, HZ>> что есть еще более грязный хак.

AB> Hе. Hе так. Hе пройдет это тогда, когда на этот объект есть ссылки из AB> других объектов, взаимодействующих с ним.

Это почему же? Вот есть у тебя объект А. И есть объект Б, который ссылается/работает с А. Если ты склонировал (путем побайтового копирования) А1 из А, то сам по себе А не изменился, и все "взаимоотношения" с Б остались на прежнем уровне. А1, конечно, хотя и точная копия А, не может, в общем случае, быть заменой А - это ведь другой объект.

А я имел в виду другое. Вот есть объект А, у которого есть, например, закрытые поля и определенный пользователем оператор присваивания и/или определенный пользователем конструктор (копирования). Объект содержит закрытое поле Flag - флаг/признак какого-то события. Этот флаг по (замыслу) устанавливается только с помощью функции-члена void SetFlag(), которая вызывается в строго определенных условиях, которые нужно зафиксировать путем установки этого флага внутри объекта. Такая вот семантика задумана.

И наш определенный пользователем оператор присваивания/конструктор копирования при копировании данных объекта А в А1 копирует все поля, кроме поля Flag - таков замысел: в новом объекте этот флаг будет установлен тоже точно так же при возникновении тех самых определенных условий. В этом весь смысл. И разработчик типа (класса), закладывая такую функциональность, предполагает вполне определенное поведение - значение флага может быть изменено только с помощью специальных функций-членов и никак иначе, - в противном случае произойдет скрытное изменение семантики типа.

А если копировать просто побайтово, то даже при правильном приведении типов возможно это самое скрытное изменение семантики и, как следствие, непредсказуемое поведение программы. Поэтому копирование не-POD типов с помощью простого побайтового копирования является дырой в системе типов, по какой причине оно и запрещено. И нарушение оного запрета - _очень_ грязный хак, использование которого есть _очень_ плохой стиль!

[...]

HZ>> А представь себе, что копирование HZ>> производится в одной единице трансляции, а приведение в другой.

AB> Что есть единица трансляции?

Ну, это, в контексте С/С++, исходный файл (.с, .срр), который подается на вход компилятору (заголовки, ессно, единицами трансляции не являются).

...so long!

### Нельзя же все ломать, надо на чем-то и сидеть.

Reply to
Harry Zhurov

Alexey Boyko wrote to "Harry Zhurov" <Harry Zhurov on Thu, 25 Sep 2003 13:04:12

+0400:

AB>>> По индексу в массиве. Одномерные массивы не есть чем-то очень AB>>> сложным и тяжелым для понимания. HZ>> А они в С/С++ только одномерными и бывают. int A[5][4] - это тоже HZ>> одномерный массив размером [5]*[4].

AB> ??? чего-то тебя не в ту степь понесло.

Может и не в ту, это ты потом еще раз реши. Давай разберемся.

Да, слово "многомерный" массив часто употребляют, имея в виду массивы вида:

int A[n][m];

Это бывает удобно, и чаще всего функциональность такого массива соответствует функциональности двумерного массива - поясню: возможно, тут есть некоторая неразбериха в терминах, что понимать под двумерным массивом?!

Двумерный массив - это массив из элементов, каждый из которых определяется двумя координатами (аргументами). Это как значения функции двух переменных, вернее, табличное задание такой функции. Соответственно, любой элемент должен быть задан двумя координатами, и попытка задания только одной координаты (аргумента) должно приводить к ошибке вида: "Ошибка: попытка получить элемент по одной координате. Массив не содержит таких элементов, каждый элемент определяется двумя аргументами". Т.е. если есть _двумерный_ массив:

int A[n][m];

то любой элемент этого массива описывается как

A[i][j];

а выражение:

A[i];

просто не имеет смысла! Вообще!!

Теперь рассмотрим массивы языков С/С++. Что означает объявление:

int A[n][m];

Оно означает массив _массивов_ элементов типа int. И, соответственно, выражение:

A[i];

означает _указатель_ _на_ _массив_ _элементов_ _типа_ _int_. Т.е. это выражение, в отличие от предыдущего случая, уже имеет вполне определенный смысл, хотя ошибки, обычно, это не устраняет - если написать так:

int x = A[2];

то получишь ошибку вида: "Невозможно преобразовать int* в int".

Зато можно обращаться с этим массивом, например, так:

int x = **A; // извлечение первого элемента из А

int y = **(A + 1); // извлечение первого элемента из второго // подмассива массива А

int x = *(*A + 2); // извлечение третьего элемента из первого // подмассива массива А

Согласись, что довольно странный синтаксис для работы с двумерным массивом!? Но зато вполне соответствующий массиву массивов.

Кстати, еще момент: вот второй пример из приведенных выше:

int y = **(A + 1); // извлечение первого элемента из второго // подмассива массива А

Будь А полноценным двумерным массивом - т.е. законченным, целостным объектом, то выражение:

А + 1

означало бы адрес следующего такого двумерного массива, первый элемент которого вычислялся бы по адресу:

&A + sizeof(A)

Но реально это не так, и выражение:

А + 1

указывает на второй подмассив, адрес которого вычисляется как:

&A + sizeof(*A)

Это происходит потому, что А - это не двумерный массив, а массив массивов, и имя массива при операциях адресной арифметики (а также при передаче в качестве аргумента функции) неявно преобразовывается в указатель на первый элемент этого массива. Таким образом, в выражении:

А + 1

А имеет тип int (*)[m], т.е. указатель на _массив_ из m интов - указатель на первый элемент массива. А этот первый элемент, в свою очередь, является тоже массивом, что и подтверждает то, что A[n][m] - это массив массивов.

Надеюсь, ты не будешь спорить с тем, что двумерный массив и массив массивов - это разные вещи? Причем, "разность" их не терминологическая (тогда можно было бы называть и так, и так безо всяких последствий), а принципиальная, проявляющаяся в разном поведении, которое подробно рассмотрено на примере выше.

Ну, и, наконец, массив массивов - это _ОДНОМЕРНЫЙ_ массив из элементов, которые также являются массивами (а могут быть элементами любого другого типа - целые, структуры, объекты классов и т.д.). И никаких многомерных массивов в С/С++ не было и нет.

Вот теперь ты снова реши, в ту ли степь меня понесло или нет?! :)

AB>>> А так руками нужно описывать разные классы. Если в программу с AB>>> массивами нужно добавить еще одно значение, нужно просто удлиннить AB>>> массивы, HZ>> Hе, не все так безоблачно. Придется объявить функцию и поместить HZ>> указатель на нее в _строго_ _определенное_ место в массиве, и не дай HZ>> Бог ошибиться. А еще учти, что функция не одна, их несколько - в нашем HZ>> небольшом примере их было три. Т.е. нужно создать три функции и HZ>> поместить указатели на них в три разных массива по одинаковому HZ>> индексу. Все это руками. И не ошибиться, т.к. компилятор это не сможет HZ>> проверить. Короче, куча манипуляций, требующая предельного внимания.

AB> Вижу, ты очень сильно заплюсовался. Hикаких функций писать я не предлагал. AB> В массивах max, min, delta я предлагал хранить числа, а не адреса функций.

Ну, тогда я вообще ничего не понял - как ты собираешься реализовать ту функциональность, которая была приведена в том примере:

// ---------------------------------- ... if( keySelect.IsClick() ) CurrentParameter++; if( keyPlus.IsClick() ) CurrentParameter->Increase(); if( keyMinus.IsClick() ) CurrentParameter->Decrease(); ... // ----------------------------------

Как ты предлагаешь достичь того же без функций, а только с помощью какого-то массива?

AB>>> а на С++ - создать новый класс. Сколько еще строк понадобится? HZ>> А ты что, трудоемкость в строках измеряешь?

AB> В конце концов все сводится к количеству строк.

:) Ну хорошо, что хоть не к ж..почасам! :))

AB>>> с которыми АВРу не очень удобно работать. HZ>> А это еще почему? И кому тогда удобно?

AB> ldd ZL, Y+N AB> ldd ZH, Y+N+1 AB> icall

AB> (это если Y свободный)

А и не обязательно его использовать для загрузки адреса в Z. Есть еще много подходящих способов.

AB> против:

AB> rcall

Во-первых, первый и второй варианы предоставляют весьма различную функциональность, поэтому говорить, что первый вариант отстойный, и надо пользоваться вторым, т.к. он эффективнее, не слишком разумно. Они не лучше или хуже друг друга, они просто разные.

Во-вторых, много команд в первом варианте берется из-за того, что процессор-то 8-разрядный, а адреса-то 16-разрядные. И во втором случае у тебя размер "прыжка" всего +-4 килобайта, в отличие от первого, где адрес полноценный. Если сравнивать честно, то нужно использовать не rcall, а call, который тоже тащит полный адрес и занимает места соответственно. Т.ч. по эффективности оно, в этом случае, отличается всего в полтора раза.

...so long!

### На экзамене по теории вероятностей: "Девушка, какова вероятность того, что выйдя сейчас на улицу, вы встретите зеленого бегемота? - 0.5! - Почему же??? - Ну, либо встречу, либо нет!"

Reply to
Harry Zhurov

Alexey V Bugrov wrote to Harry Zhurov on Thu, 25 Sep 2003 22:58:51 +0400:

[...]

AM>>> темнишь :) AM>>> хоpоший стиль ввеpхy pазместить public, а ниже него - private

HZ>> Это с чего ты взял? Этот стиль у всех свой, и можно долго спорить, HZ>> какой лучше и правильнее.

AV> Страуструп считает иначе. Ему нельзя верить? :)

Однако книга его, 3-е издание, изобилует примерами, где у него сначала идет представление в закрытой части, а уж затем открытый интерфейс. Сам он пишет, что в более сложных случаях реального кода, когда представление объемно, он предпочитает помещать его в конце, дабы не загромождать интерфейс. Я тоже придерживаюсь такого стиля, но иногда, в простых случаях, удобно сделать наоборот, как в примерах про complex:

// ------------------------------------------------------- class complex { double re, im;

public: complex(double r, double i) { re=r; im=i; } complex(double r) // преобразование float->complex { re=r; im=0; } friend complex operator+(complex, complex); friend complex operator-(complex, complex); // вычитание friend complex operator-(complex) // унарный минус friend complex operator*(complex, complex); friend complex operator/(complex, complex); // ... }; // -------------------------------------------------------

когда представление очень простое, и удобнее не прятать его где-то в глубине, а описать сразу, чтобы было видно из чего состоит этот комплексный тип, не загромождая при этом описание интерфейса и не ухудшая читабельности.

Все зависит от конкретного случая, а также вкуса разработчика. Кстати, то, что Страуструп предпочитает делать так или иначе, не означает, что делать по-другому - плохой (неправильный) стиль.

...so long!

### Одеяла и подружки ждут ребят.

Reply to
Harry Zhurov
25-Sep-03 16:22 Harry Zhurov wrote to Oleksandr Redchuk:

OR>> INTERNATIONAL STANDARD ISO/IEC ISO/IEC 9899:1999 OR>> Programming languages - C

OR>> inline иметь положено. Уже 3 года как.

HZ> IAR C - последняя версия, afaik, 1.51, вышла где-то в 99 году. И HZ> много ты знаешь компиляторов, удовлетворяющих C99? gcc: -std=<std name> Specify the conformance standard; one of: gnu89, gnu99, c89, c99, iso9899:1990, iso9899:199409, iso9899:1999, c++98

Впрочем, полноту соответствия не знаю. Но не думаю, что с inline будут проблемы :-)

А "и много ты знаешь" -- не оправдание. Оно позволяет всем вместе хором ничего не делать, только скандировать "и много ты знаешь". Так что видать IAR просто решил забить вообще на линейку C-компиляторов, сделав упор на EC++.

HZ> Там, кстати, если и более HZ> существенные вещи - локальные динамические массивы. Какие компиляторы HZ> уже поддерживают это? gcc. Весь выводок. Кажется, с версии 3.0

int foo(unsigned char uu, unsigned char *puu) { unsigned char moo[uu]; unsigned char t; moo[uu/2] = *puu; return moo[uu/2]; }

mingw32 3.2 (20020817) компилирует с вызовом _alloca avr-gcc 3.3 (20030421) ручками резервирует место на стеке и всё делает. Впрочем, пихать это в AVR (кроме, разве что, меги128 с внешней SRAM), равно как и использовать там malloc или new - боюсь, не самое оно. Да и на меге с внешней памятью - разве что реализацию malloc с разными пулами для объектов разных размеров (может, тогда лучше сразу нормальный язык со сборкой мусора туда, а не C/C++ :-)

wbr, p.s. Э! Может лучше завяжем с этим, у тебя появится время на разборки с gcc ты знаешь для чего, и у меня время появится на разборки с ты знаешь чем для gcc :-))

Reply to
Oleksandr Redchuk
25-Sep-03 16:22 Harry Zhurov wrote to Oleksandr Redchuk:

HZ>>> Мне не понятно вот что: зашли в функцию, скопировали SP в Y, OR>> вычли из SP размер локальных переменных

HZ> Все это в критической секции?

HZ>>> начали с ним работать -

HZ> sbiw r28:r29,... ; выделили память под несколько переменных

HZ> st -Y,... ; тут сунули в стек еще переменную

Слушай, а как это сделано у IAR/MSP430 ? Неужели тоже два стека и регистр под второй указатель занят?

Напоминаю ещё раз как это сделано у x86/16 (оно короче и проще объяснить) SP - указатель стека, с которым можно кое-что сделать, но адресоваться по нему нельзя. BP - указательный регистр, который по умолчанию работает в сегменте стека и по нему удобно обращаться к стековому кадру push bp mov bp,sp sub sp,size of locals ; резервируем место Теперь sp не трогаем, обработчики прерываний в стек могут спокойно писать. Адресация относительно bp вверх - аргументы функций, вниз - локальные переменные.

Для MSP430 это должно выглядеть как sub sp,size of locals и вся адресация относительно SP в плюс.

Для AVR и адресоваться отрицательным смещением неудобно, и относительно SP нельзя (что нельзя и в x86/16, но выходит не так больлно). Итого:

/* prologue: frame size=6 */ push r16 ; это сохраняются те, кого надо сохранить push r17 ; к делу отношения не имеет push r28 push r29

in r28,__SP_L__ in r29,__SP_H__ sbiw r28,6 in __tmp_reg__,__SREG__ ; * cli ; * out __SP_H__,r29 out __SREG__,__tmp_reg__ ; * out __SP_L__,r28

После этого дела Y указывает на стековый кадр (как BP у x86/16, только Y указывает не на серёдку стекового кадра, а на низ). '*' отмечены команды, которых могло бы не быть, если бы out SPH,reg запрещала на такт прерывания.

HZ> ...

HZ> заключать любое такое изменение, дабы атомарность не потерять? Но тогда HZ> какой смысл в этом Y в качестве указателя стека, когда такой оверхед? Y не указатель стека, а указатель кадра.

HZ> Или сразу выделять по максимуму, сколько в функции нужно? Ну да. И у PDP11 так было, и, думаю, IAR/MSP430 так делает.

HZ> Причем тут 430-й? У него SP нормально сделан, он позволяет адресоваться А притом, что место под локальные переменные и на нём резервировать надо. Т.е. его надо модифицировать. В силу 16-разрядности процессора такая модификация атомарна автоматически, но она есть. Возможно, из-за атомарности ты её и не заметил.

HZ> любым штатным способом и косвенно, и со смещением, и адресная арифметика HZ> там HZ> работает, поэтому нет необходимости его значение куда-то копировать. Вот Вопрос не только копирования, но и модификации. Место под locals зарезервировать надо и для него. Просто у него STACK_POINTER := STACK_POINTER - SIZE_OF_LOCALS делается очень просто. Отсутствие адресации по указателю стека тоже не есть нечто уникальное AVR-ское, это не очень приятно, но решаемо. Но вот у AVR это усугублено элементарными "недодумками" в других местах. IAR обошёлся тем, что для данных завёл второй стек, который обслуживется отдельно и на котром легко реализуется резервирование места.

OR>> Два стека (данных и управления) -- мысль довольно неплохая.

HZ> А это в ОС используется - там зачастую удачным является решение, HZ> когда для прерываний свой стек. Какой он "свой"? Тут два стека - возвратов и данных. Прерывание работает в стеке управления основной программы, как минимум вход в него. Только потом оно может переключить указатель стека на системную область и дальше работать там.

"У прерывания свой стек" - это когда у ядра процессора есть отдельный указатель для этого и при прерывании даже PC прерываемой программы сохраняется в другом стеке.

OR>> Но, с другой стороны, требующая более аккуратного распределения OR>> памяти -- каждому стеку надо дать, и каждому чтобы хватило.

HZ> Так ведь у ИАРов два стека, правда они не такие, но тоже нужно за HZ> этим следить. О чём и говорю. В одной задачке на 4433 пришлось в код добавлять проверку уровня загаженности стеков и перераспределять место между RSTACK и CSTACK

wbr,

Reply to
Oleksandr Redchuk

Alexey Boyko wrote to "Harry Zhurov" <Harry Zhurov on Fri, 26 Sep 2003 09:40:22

+0400: [...]

HZ>> sbiw r28:r29,... ; выделили память под несколько переменных

AB> ; аналогично push BP AB> push R28 AB> push R29

AB> ; аналогично mov BP, SP AB> in R28, SPL AB> in R29, SPH

AB> ; аналогично sub SP, locals AB> sbiw R28, locals AB> in tmp, SREG AB> cli AB> out SPH, R29 AB> out SREG, tmp AB> out SPL, R28

AB> Теперь SP продолжает указывать на вершину стека, а Y - на кадр стека AB> Стек то один.

HZ>> st -Y,... ; тут сунули в стек еще переменную HZ>> ...

AB> Зачем? Переменные и так в распределены в стеке. Если нужно сохранить AB> что-то, AB> то push/pop

// -----------------------------------

extern int key; void f() { char buf[16]; long x = 5; ...

switch(key) { case 1: { ... // f1(); // функция, которая жрет много стека } break;

case 2: { int buf[32]; // буфер, который жрет много стека ... // } }

} // -----------------------------------

Сколько памяти нужно выделять? Если по твоей технологии, то нужно просмотреть всю функцию и выделить по максимуму: 16 + 1*4 + 32*2 = 84 байта. В стеке. Но если поток управления пойдет по первой ветке, то выделять память под буфер во второй не нужно, и память эта может оказаться очень не лишней при вызове функции из первой ветки, которая (функция) тоже прилично хавает стека. Если по второй ветке, то придется выделять по максимуму, но зато нет жручих функций. Таким образом, если выделять не все сразу, а смотреть по ходу дела, то получается более эффективное расходование памяти, а если все сразу, то, соответственно, неэффективное.

HZ>> Это что, после каждого такого обращения SP модифицировать?

AB> Теперь понял?

Понял, понял, но не могу признать это лучшим, чем использование отдельного стека для данных, как это сделано в ИАРе.

AB> Если компилировать с опцией -mno-interrupt, тогда при сохранении SP, AB> нет шаманства с SREG, а просто

Зато можно получить по полной программе в случае возникновения прерывания во время изменения SP.

AB> А был бы SP регистром, то вообще:

AB> push R28 AB> push R29 AB> sbiw R28, locals AB> movw SP, R28

Будь он регистром, то просто обязан быть указателем.

HZ>> Причем тут 430-й? У него SP нормально сделан, он позволяет HZ>> адресоваться любым штатным способом и косвенно, и со смещением, и HZ>> адресная арифметика там работает, поэтому нет необходимости его HZ>> значение куда-то копировать. Вот если бы в том же AVR Y-pointer был бы HZ>> одновременно и SP (т.е. был бы способен участвовать в процессе HZ>> запоминания адресов возвратов из функций и прерываний), то всего этого HZ>> геморроя не было бы. Правда тогда там осталось бы полтора указателя.

AB> Можно было убрать in/out, а вместо них сделать 4 регистровых пары AB> указателя.

AB> r24:r25, r26:r27, r28:r29, r30:r31

AB> Это было бы намного лучше.

Ну, давай помечтаем: оставить 16 регистров, которые образуют 8 регистровых пар-указателей. Все регистры полностью равноправны. Обращение в память производится за один такт. При входе в прерывание SREG аппаратно сохраняется в стеке, а при возврате восстанавливается... Ну, ладно, как говорит батя моего друга: "Слезай, а то сломаешь!" ;-))

AB> А еще можно было убрать половину регистров, так как только половина из них AB> нормальные, а остальные используются только как временное хранение.

А avr-gcc, вроде, позволяет заблокировать произвольное количество регистров от использования компилятором?

...so long!

### Тяжело в мyчении - легко в гpобy.

Reply to
Harry Zhurov

Oleksandr Redchuk wrote to "Harry Zhurov" snipped-for-privacy@online.nsk.su> on Fri, 26 Sep 2003 19:36:35 +0000 (UTC):

[...]

HZ>> st -Y,... ; тут сунули в стек еще переменную

OR> Слушай, а как это сделано у IAR/MSP430 ? Неужели тоже два стека и регистр OR> под второй указатель занят?

Нет, стек один. Там SP все умеет - и адресоваться как угодно, и адресную арифметику одной командой.

OR> Напоминаю ещё раз как это сделано у x86/16 (оно короче и проще объяснить) OR> SP - указатель стека, с которым можно кое-что сделать, но адресоваться OR> по нему нельзя. BP - указательный регистр, который по умолчанию работает OR> в сегменте стека и по нему удобно обращаться к стековому кадру OR> push bp OR> mov bp,sp OR> sub sp,size of locals ; резервируем место OR> Теперь sp не трогаем, обработчики прерываний в стек могут спокойно OR> писать. Адресация относительно bp вверх - аргументы функций, OR> вниз - локальные переменные.

Да, Алексей уже объяснил, спасибо.

OR> Для MSP430 это должно выглядеть как OR> sub sp,size of locals OR> и вся адресация относительно SP в плюс.

Именно так и выглядит:

SUB.W #0x50, SP ; выделено 80 байтов стеке

[...]

HZ>> Или сразу выделять по максимуму, сколько в функции нужно? OR> Ну да. И у PDP11 так было, и, думаю, IAR/MSP430 так делает.

Да, так делает, хотя мог бы и оптимизировать, ничто этому не мешает.

HZ>> Причем тут 430-й? У него SP нормально сделан, он позволяет HZ>> адресоваться OR> А притом, что место под локальные переменные и на нём резервировать OR> надо. Т.е. его надо модифицировать. В силу 16-разрядности процессора OR> такая модификация атомарна автоматически, но она есть.

У AVR модификации 16-разрядных указателей тоже атомарны.

OR> Возможно, из-за атомарности ты её и не заметил.

:) Еще как заметил. Из-за этого кое-где в обработчиках прерываний возникают з..цы...

[...]

HZ>> А это в ОС используется - там зачастую удачным является решение, HZ>> когда для прерываний свой стек. OR> Какой он "свой"? Тут два стека - возвратов и данных. OR> Прерывание работает в стеке управления основной программы, OR> как минимум вход в него. Только потом оно может переключить OR> указатель стека на системную область и дальше работать там.

OR> "У прерывания свой стек" - это когда у ядра процессора есть OR> отдельный указатель для этого и при прерывании даже PC прерываемой OR> программы сохраняется в другом стеке.

А вот это не понял: как это реализуется физически? На аппаратном уровне, что ли? И какой смысл в этом? Насколько я понимаю, адрес возврата как раз и нужно запоминать в стеке прерванного процесса, чтобы потом, когда нужно передать управление этому процессу, извлечь адрес из стека данного процесса.

...so long!

### Она была от счастья на седьмом месяце...

Reply to
Harry Zhurov

Hello "Harry.

26 Sep 03 21:35, you wrote to me:

HZ>>> А они в С/С++ только одномерными и бывают. int A[5][4] - это HZ>>> тоже одномерный массив размером [5]*[4]. AB>> ??? чего-то тебя не в ту степь понесло.

HZ> Будь А полноценным двумерным массивом - т.е. законченным, HZ> целостным объектом, то выражение: HZ> А + 1 HZ> означало бы адрес следующего такого двумерного массива,

Это эще почему? 'A' ведь не является указателем на объект, а есть сам объект. (Я не имею в виду, что в Си можно имя массива использовать как указатель)

HZ> Hадеюсь, ты не будешь спорить с тем, что двумерный массив и массив HZ> массивов - это разные вещи?

Что то я в этом не уверен. Если массив разных массивов, тогда разница есть, но в Си нельзя без хаков объявить массив разных массивов.

HZ> Вот теперь ты снова реши, в ту ли степь меня понесло или нет?! :)

Тебя понесло в математическое философствование. Я же отношусь к массиву по простому - по программистскому. ;)

AB>> Вижу, ты очень сильно заплюсовался. Hикаких функций писать я не AB>> предлагал. В массивах max, min, delta я предлагал хранить числа, а AB>> не адреса функций. HZ> Hу, тогда я вообще ничего не понял - как ты собираешься HZ> реализовать ту функциональность, которая была приведена в том примере:

HZ> // ---------------------------------- HZ> ... HZ> if( keySelect.IsClick() ) CurrentParameter++; HZ> if( keyPlus.IsClick() ) CurrentParameter->Increase(); HZ> if( keyMinus.IsClick() ) CurrentParameter->Decrease(); HZ> ... HZ> // ----------------------------------

HZ> Как ты предлагаешь достичь того же без функций, а только с помощью HZ> какого-то массива?

дык я же вроде приводил кусочек кода.

if (keySelect.IsClick()) // В данном случае я не рассматриваю опрос кнопок CurrentParameter = (CurrentParameter+1) % ParameterCount;

if (keyPlus.IsClick()) { if ((current[CurrentParameter] += delta[CurrentParameter]) >

max[CurrentParameter]) { current[CurrentParameter] = max[CurrentParameter]; }

if (keyMinus.isClick()) { if ((current[CurrentParameter] -= delta[CurrentParameter]) < min[CurrentParameter]) { current[CurrentParameter] = min[CurrentParameter]; } }

Я не предлагаю реализовывать функциональность С++ на Си. Просто на Си принято по другому писать.

Видел GTK+? это реализация С++ функциональности на Си. Жуткая штука. Hо работает.

HZ> Во-первых, первый и второй варианы предоставляют весьма различную HZ> функциональность, поэтому говорить, что первый вариант отстойный, и HZ> надо пользоваться вторым, т.к. он эффективнее, не слишком разумно. Они HZ> не лучше или хуже друг друга, они просто разные.

Да.

HZ> Во-вторых, много команд в первом варианте берется из-за того, что HZ> процессор-то 8-разрядный, а адреса-то 16-разрядные.

Вот я привел пример для 32-х разрядного.

Alexey

Reply to
Alexey Boyko

Hello "Harry.

27 Sep 03 07:07, you wrote to me:

HZ> Сколько памяти нужно выделять? Если по твоей технологии,

Это не моя технология. Это так gcc работает.

HZ> то нужно HZ> просмотреть всю функцию и выделить по максимуму: 16 + 1*4 + 32*2 = 84 HZ> байта. В стеке. Hо если поток управления пойдет по первой ветке, то HZ> выделять память под буфер во второй не нужно, и память эта может HZ> оказаться очень не лишней при HZ> вызове функции из первой ветки, которая (функция) тоже прилично хавает HZ> стека. Если по второй ветке, то придется выделять по максимуму, но HZ> зато нет жручих функций. Таким образом, если выделять не все сразу, а HZ> смотреть по ходу дела, то получается более эффективное расходование HZ> памяти, а если все сразу, то, соответственно, неэффективное.

Зависит от логики компилятора. gcc вроде бы выделяет по максимуму. Hо никто не мешает ему выделять дополнительно кадр в каждом блоке.

HZ> Понял, понял, но не могу признать это лучшим,

Так делается в подявляющем большинстве процессоров и компиляторов.

HZ> чем использование HZ> отдельного стека для данных, как это сделано в ИАРе.

В IARе память выделяется точно также, только с регистром Y

AB>> Если компилировать с опцией -mno-interrupt, тогда при сохранении AB>> SP, нет шаманства с SREG, а просто HZ> Зато можно получить по полной программе в случае возникновения HZ> прерывания во время изменения SP.

Естественно. Поэтому, обычно, компилируют без -mno-interrupt

AB>> А был бы SP регистром, то вообще: HZ> Будь он регистром, то просто обязан быть указателем.

Я бы не адресовался в кадр стека по SP, а все-таки по frame-pointer'у так как это накладывает ограничения на на push/pop в самой функции

AB>> А еще можно было убрать половину регистров, так как только AB>> половина из них нормальные, а остальные используются только как AB>> временное хранение.

HZ> А avr-gcc, вроде, позволяет заблокировать произвольное количество HZ> регистров от использования компилятором?

Можно. Hо от этого они указателями не станут. ;)

Alexey

Reply to
Alexey Boyko
27-Sep-03 12:36 Alexey Boyko wrote to "Harry Zhurov" <Harry Zhurov:

HZ>> Как ты предлагаешь достичь того же без функций, а только с помощью HZ>> какого-то массива?

AB> дык я же вроде приводил кусочек кода.

AB> if (keySelect.IsClick()) // В данном случае я не рассматриваю опрос AB> кнопок AB> CurrentParameter = (CurrentParameter+1) % ParameterCount;

AB> if (keyPlus.IsClick()) { AB> if ((current[CurrentParameter] += delta[CurrentParameter]) >

AB> max[CurrentParameter]) { AB> current[CurrentParameter] = max[CurrentParameter]; AB> } Даже не так, а в таком духе (всё сложнее, это так, псевдокод).

u08 key; do { key=GetKey(); switch( key) { case KEY_ESC: break;

case KEY_LEFT: case KEY_RIGHT: if( fNeedSave) SaveParameter( parampage, paramno); if( KEY_LEFT) { if( --paramno < 0) paramno = maxparam[ parampage]; } else { if( ++paramno > maxparam[parampage] ) paramno = 0; } LoadParameter( parampage, paramno); break;

case KEY_INC: ++parameter; // и т.д.

} while( key != KEY_ESC);

На самом деле параметры описываются массивами структур во флеше, массивами указателей на эти массивы и т.п. Всё инициализируется статически, да, структура меню жёстко забита во флеше. У каждого параметра в структуре описателя - его тип (int, byte, string), начальный адрес в EEPROM, длина (для строк), min и max значения (для int/byte), после смены параметра по ещё одному небольшому switch() вызывается нужная функция Edit() (и уже она делает GetKey() и разбирает INC/DEC/CLR, по KEY_UP возвращается на уровень перебора параметров). Итого всё меню конфигурирования - это немножко кода и таблицы констант, которые занимают _гораздо_ меньше места, чем если бы это всё реализовывать в виде функций или кода по switch(). В некотором смысле машина состояний, заданная в виде таблиц переходов, а не в виде структуры кода. И в итоге нет никаких многоэтажных switch, которые предлагается заменить на виртуальные функции и (всё равно!) массив указателей на экземпляры классов Parameter, по которому ходит указатель CurrentParameter.

AB> Просто на С принято по другому писать. Вот именно. И, самое главное, это все не есть "попытка эмуляции средствами C поведения C++".

wbr,

Reply to
Oleksandr Redchuk

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.