Формат за разпечатване

[Jack Johnson]

Чудесно показно за способностите за "езикова мимикрия" и емулация на език от по-ниско ниво чрез език от по-високо, и по този начин - демонстрация на изчислителната пълнота и следствията от нея.

;)

Хм-м-м, може да се поспори по въпроса кой език е на високо и кой на ниско ниво. Дълги години съм програмирал на всякакви видиве BASIC и за мен този език е всичко друго, но не и "език от по-ниско ниво".

А и по какви критерии ще сравняваме двата езика?

Простота на конструкциите? Времето, необходимо за изучаване на езика? Времето, необходимо за написване на пълноценна програма?

И по трите критерия BASIC засега е ненадминат.

Иначе и Java я бива за туй-онуй... 

P.S. Аз съм загубена кауза, и след 30 години за мен BASIC ще си остане Най-Великият Сред Великите Език За Програмиране.

[Tosh]

Здравей,

Аз имах предвид Бейсик с класически черти:

- Номерирането на редовете и неизбежното GOTO е като на машинен език.

- Няма абстракции за подпрограми и параметри. GOSUB, RETURN и GOTO са аналогични съотв. на JSR, RTS и JMP напр. за 6502, така че програмистът трябва да мисли за разклонените алгоритми както ако пише на маш. език и дори трябва сам да разпределя паметта - номерата на редовете и на кои какво се намира.

- Няма създаване на нови типове и на абстрактни типове данни /освен вграден низ/.

- Само всеобщо видими променливи; половинчата абстракция за "съставен оператор" /което е на един ред.../

- Няма рекурсия.

...

По-късните усъвършенствани бейсици и псевдобейсици /като DarkBASIC/ очевидно не са "истинският Бейсик", за който стана дума в "езиковата мимикрия" с Джава.

Поздрави

[Jack Johnson]

Та като стана дума за асемблер, кой ще отговори на следната "лесна" гатанка:

Какво означава последователността от следните букви и цифри:

B44CCD21

Подсказвам, това е оп-кодът на програма, писана на асемблер за Intel x86 Real Mode.

[prestor]

Край на програмата ли?

[Jack Johnson]

Край на програмата ли?

Точно така:

B44C: MOV AH, 0x4C
CD21: INT 0x21

В рамките на старото DOS API това е най-дългият и елегантен начин да прекъснеш изпълнението на COM или EXE.

Има и още два начина:

CD20: INT 0x20 - Това прекъсване е малко deprecated и извикването му води до изпълнението на гореспоменатата 4-байтова програма само за съвместимост(май така беше... ама и да не е така то кой ли се занимава в днешно време с асемблер )

RET - Не му помня оп-кода, а и сработва само ако стекът на програмата е празен, при което управлението се предава на всемогъщия COMMAND.COM

Сега си спомням за оня проект с графиката, дето целия курс трябваше да го пишем на асемблер преди 4 години! За щастие на по-модерните зайци, те никога няма да изпитат тръпката от програмиране на толкова ниско ниво! Освен ако някой не се захване с чудовището, наречено MSIL Assembler за .NET Framework (на никого не го препоръчвам, толкова е кофти колкото и изучаването на нормален асемблер, ако изобщо можем да си говорим за норамлен асемблер)!

В името на CTRL, ALT и светия DEL:

ENTER

[Tosh]

Здравейте,

> ама и да не е така то кой ли се занимава в днешно време с ?асемблер

Кой ли се занимава днес със системните функции на DOS, не с асемблер... ;) Демота, програмиране на графични процесори, любители на ниското ниво, програмисти на микроконтролери и на MenuetOS...

>Сега си спомням за оня проект с графиката, дето целия курс
>трябваше да го пишем на асемблер преди 4 години!

Ще споделиш ли нещо повече за тоя проект?
Аз ще споделя статията си "Анализ на почти празен цикъл", в която пиша за тестове на Правец-8М, 8Д, Pentium 90 и Pentium 200 MMX на ниско и високо ниво и с различни машинни езици, асемблери и компилатори. :lol:

http://eim.hit.bg/eim21/analiz_21.htm
http://geocities.com/eimworld/eim21/analiz_21.htm

и "Как се чертае отсечка" в режим $13 с около 75 инструкции на 8086.

http://geocities.com/eimworld/eim22n/eim24/otsechka.htm


И не се въздържам да цитирам поне мъничко от първата статия.  

Използвано е юнашко наречие...  ;)
-----------
...
"Първият": Правец-8М, 6502/1.018 MHz
За любимия си Емчо съчиних следното стихче на вършачопис, което драгият MONITOR преведе на глаголица:

300: A9 00       LDA #$00, 2
302: 8D 00 50  STA $5000, 4
305: A2 00       LDX #00, 2
307: A0 00       LDY #00, 2
309: EE 00 50  INC $5000, 6
30C: 69 01      ADC 01, 2
30E: C9 10     CMP #$10, 2
310: F0 03      BEQ $0315, 2
312: 4C 09 03  JMP $309, 3
315: A9 00       LDA #00, 2
317: E8            INX, 2
318: E0 10       CPX #$10, 2
31A: F0 03        BEQ $031F, 2
31C: 4C 09 03  JMP $309, 3
31F: A2 00        LDX #00, 2
321: C8            INY, 2
322: C0 10       CPY #$10, 2
324: F0 03        BEQ $329, 2
326: 4C 09 03  JMP $309, 3
329: 20 DD FB  JSR $FBDD, 6 (ЗВЪНЧЕ)
32C: 60             RTS, 6

Както се вижда, в него освен празната въртележка, има и увеличаване с единица на клетка от паметта ($309: INC $5000), което е доста тежка казба за 6502 - цели 6 удара на сърцето... Сигурно също се вижда, че натрапващата се шестнайска ($10) е броят повторения и на трите вложени въртележки, следователно:

Общият брой цикления е N*N*N = N^3.

За лесно въвеждане на N бе написано кратко глаголище на личната ми програмистка "Основа" - BASIC.

10 N = 250 (N, M = N*N*N)
20 POKE 783, N
30 POKE 793, N
40 POKE 803, N
50 CALL 768
Като завъртях сметачето на въртележката (1.018 MHz), при N = 250 (M = 250^3 = 15.625E6), то се наигра за около 231.7 секунди, като постигна скорост от около 1018000/231.7 = 67436 врътки/сек. "Брей, не е малко" - си рекох и погледнах стихчето, за да преброя колко казби има във всяка врътка на най-вътрешната въртележка. Пет са, като ги гледам:

309: EE 00 50   INC $5000, 6
30C: 69 01   ADC 01, 2
30E: C9 10   CMP #$10, 2
310: F0 03   BEQ $0315, 2
312: 4C 09 03   JMP $309, 3

Тогава 67346*5 = 336730 казби/сек... Ех, да не беше това INC $xxxx, то изяжда 40% от цялото време (6/15). Все пак, и 67346/сек не са малко за сметачето...

Колко обаче са на BASIC?

5 N = 20
10 I = 0: J = 0; K = 0
20 C = 0
50 FOR I = 1 TO N
60 FOR J = 1 TO N
70 FOR K = 1 TO N
80 C = C + 1
90 NEXT: NEXT: NEXT
100 ?CHR$(7)(ЗВЪН)

Пуснах глаголището при N = 20 и то изглаголи всичко за около 31.2 секунди, или 20*20*20 = 8000; 8000/31.2 = 256/сек. Брей, че бавно... Тогава махнах ред 80, да бъде само празна въртележка, и милото свърши само за 9.2 сек - около 870 врътки/сек.

256/сек, при около 250-350 хил. казби/сек (както установихме по-горе) означава, че мекицата на BASIC изпълнява поне около 1000 казби за всяка врътка...
...
-----------

Поздрави

[Дамян Митев]

Еееех, Тошо, връщаш ме в сладката прегръдка на детството и добрия стар Правец8-М, монохромния монитор и скапаното, но безценно 5.25" флопи, голямо като гардероб ....

Както и да е, отклонихме се от темата.
Попита за проекта по асемблер. Задачата беше на асемблер да се напише малка програма (в случая игра), която да демонстрира основни познания за езика, пък и не чак толкова основни. Аз и колегата Даводов, заедно с Димитров и Георгиева сътворихме невероятна игра, в която ловец стряля по прелитащи патки. Само дето звук нямаше, но амимацията бе веднъж. Специално създадохме иновативен векторен енджин за графиката (по идея на Даводов). Разбира се за изчертаване на правите и дъгите изполвахме алгоритъма на Бреш, който е възможно най-добрия!
С две думи - беше невероятно приключение и почти съжалявам, че вие няма да се насладите на тръпката


А по темата за четимостта на кода - в университета никой не ни учи на работа в екип (или ако има проекти за двама те или се пишат само от единия, или двамата пишат отделни парчета и после сглобяват). За съжаление в реалния свят програмистите много често работят по един и същи сорс, или един трябва да коригира сорс на друг.  В този случай е жизненоважно да има накаква (дори елементарна) конвенция и мнооого коментари. По тази причина за мен винаги е било минус изполването на някои "яки" оператори в езици като С++ и Java, като например инициализиране на няколко променливи в скобите на for-цикъла или използването на тернарния оператор (е не винаги) и особено едновременното присвояване на стойност на променлива и тестването й в if() условие. Според мен кода трябва да следва блок - схемата на програмата, а не да се вие по тънките оператори на езика.

А за GOTO: по принцип не съм фен на GOTO-програмирането (където на всеки 2 реда има по някое и друго GOTO), но този оператор представлява една от основните инструкции наред с присвояването, и неговото тотално отричане е меко казано глупаво  . Има е случаи, в които използването на едно GOTO спестява писане на доста код и реално прави програмата по-разбираема (глупаво е да се напише безкраен цилъл и в него да се сложи break само и само  да не се напише GOTO). Съвсем наскоро имах такъв инцидент ;)

[Jack Johnson]

Аз и колегата Даводов...

Според Ненка Трайкова за последните 10 години в нашия факултет не е стъпвал никой с фамилия "Даводов", така че, колега Митев, провери си правописа!

Иначе енджина наистина беше жесток! Поддържа цели осем векторни посоки, осем битов цвят и дължина на правата пак от порядъка на 8 бита, което прави 256 пиксела за една отсечка, в това число и по диагонал! Обектът, който трябва да се изчертае се представя като непрекъсната последователност от байтове с променлива дължина, групирани по тройки, при което на енджина само му се указват началните X и Y координати и адресът, на който се намира първия байт от обекта. Тази абстрактност ни позволи да си дефинираме лесно и бързо всякакви обекти и да ги пльосваме където си искаме по екрана , което ни даде достатъчно време да сътворим истински 2D shooter, което като оценки ни донесе общ сбор от 30 точки(в екипа бяхме пет човека, 3 момчета и 2 момичета, друг е въпросът кой е правил нещо и кой е спал).

И това нещо е създадено от хора, които по онова време са били първи курс, по на 18-19 години, при това изцяло на асемблер.

Тошко, ако наистина те интересува, сорсът е писан на TASM, пази ги колегата Димитров, ще му кажа да ги ъплоудне някъде или направо да ти ги прати.

[Tosh]

Кефите, пичове...  :lol:

>заедно с Димитров и Георгиева сътворихме невероятна игра, в която ловец стряля по прелитащи патки."

Хе-хе, може би нещо като "Ловна стрелба" за Правеца?

"Поддържа цели осем векторни посоки, осем битов цвят и дължина на правата пак от порядъка на 8 бита, което прави 256 пиксела за една отсечка, в това число и по диагонал!"

Т.е. чертае така:

| --  /  \  а не произволни отсечки?


"Тошко, ако наистина те интересува, сорсът е писан на TASM, пази ги колегата Димитров, ще му кажа да ги ъплоудне някъде или направо да ти ги прати."

Да, бих се радвал на всичко възможно, което съхранявате по този проект!

>Разбира се за изчертаване на правите и дъгите изполвахме алгоритъма на Бреш, който е възможно най-добрия!

Бреш съкратено от Breshenham ли е или е друг?

Поздрави

[Nikolay Manchev]

Иначе енджина наистина беше жесток! Поддържа цели осем векторни посоки, осем битов цвят и дължина на правата пак от порядъка на 8 бита, което прави 256 пиксела за една отсечка, в това число и по диагонал...

Като го чета това и направо се забавлявам как различните хора подхождат към едни и същи проблеми... Аз принципно понеже съм мързел и за всяко нещо гледам да намеря някакъв hack, когато писах тоя проект си натворих спрайтовете за анимацията с растерен редактор и после на асемблер си написах само зареждачка от файловете с данните. Никакви енджини, никакви вектори... Цялата работа я свърших за 2 дни. Е, то верно после че на асистента му идваше да ми махне главата, ама нищо не можа да каже - нямаше условие в проекта кое как да се направи 

Поздрави,

Николай Манчев

[VooDooMaN]

Можем да си отворим нова тема "Source treasury", но на първо време го пускам тук . Днес се натъкнах на следния код:

String strCurrentDate = DateTimeUtils.formatDate(Calendar.getInstance().getTime());
Date currentDate = ParseUtils.parseDate(strCurrentDate);