Linux за българи: Форуми

Здравейте, може ли някой да ми обясни по по-простичък начин разликата между системните и приложните програмни езици. По няколко примера за всеки, кои са по лесни за усвояване за новак, Python от кои точно е и къде се използват едните и другите?

Така-а-а.  ;D Ай сега де? Добре. Ще се пробваме. Казано най-ламерски системни са тези дето можеш да пишеш основата на операционна система на тях. Не е точно академично обяснено, а нямам и образование.

Приложни, отново името подсказва. На тях можеш да пишеш приложения в най-широкия смисъл на думата.

Смоку не може да влезе в нито едната от двете групи. Смоку е свободен. А свободата чупи граници и зъби. Смоко не подлежи на академични определения. На него се пише всичко.

Сега ще изненадам хората дето знаят колко обичам тоя език, ама не е за теб. Първо мини из цялата академична месомелачка и едва тогава го хвани в ръце. Едва тогава ще го оцениш. Казва ти го човек дето си чупеше главата сам, когато тук почти никой не беше чувал за Смоку, а идвах от бъзик и не виждан.

Споко, ако те обърках съвсем, сега ще додат ората с дипломите да обяснят нещата.

Така-а-а.  ;D Ай сега де? Добре. Ще се пробваме. Казано най-ламерски системни са тези дето можеш да пишеш основата на операционна система на тях. Не е точно академично обяснено, а нямам и образование.

Приложни, отново името подсказва. На тях можеш да пишеш приложения в най-широкия смисъл на думата.

Смоку не може да влезе в нито едната от двете групи. Смоку е свободен. А свободата чупи граници и зъби. Смоко не подлежи на академични определения. На него се пише всичко.

Сега ще изненадам хората дето знаят колко обичам тоя език, ама не е за теб. Първо мини из цялата академична месомелачка и едва тогава го хвани в ръце. Едва тогава ще го оцениш. Казва ти го човек дето си чупеше главата сам, когато тук почти никой не беше чувал за Смоку, а идвах от бъзик и не виждан.

Споко, ако те обърках съвсем, сега ще додат ората с дипломите да обяснят нещата.

 ;D ;D ;D благодаря за инфото  [_]3 Чакам и други мнения

По принцип аз знам за System programming (Системно програмиране) и Application programming (Приложно програмиране). Ще се опитам с няколко думи и без претенции за пълна прецизност да разкажа...

Системно програмирене е да пишеш програмки, които да си говорят директно с ОС, изискват услуги от нея, управляват ресурсите ѝ. Примери за системен софтуер са основните команди, които пускаш от конзола (coreutils в GNU) - cat, wc, ls, head и т.н., различните сървъри за услуги (уеб сървъри (apache и ко), пощенски сървъри (postfix и ко), СУБД(postrgres и ко) и т.н.), програмирането на ядра и модули за ядра мисля, че също влизаше, програмирането на компилатори и интерпретатори за езици за програмиране, програмки от сорта на mdadm, lmsensors и неща в подобен дух.

За да си говори директно със системата, системният софтуер ползва основно библиотеките за езика си и системните функции (примитиви, ABI) на твоята ОС.

Приложен софтуер е нещо като едно ниво над системния. Например - nautilus, dolphin и ко са файлови мениджъри, които ти използваш, за да си управляваш файловете. Те са направени с удобен интерфейс, ориентиран в услуга на теб, потребителя. На практика те са една приложна обвивка на системни програми като ls, cp, mv, rm и т.н. Системните програми често дефинират API, чрез което приложните програми да могат да се свързват с тях и да ги викат в своя услуга.

Приложен софтуер (application) е твоя уеб браузър, пощенски клиент, phpMyAdmin, графичните инструменти за конфигуриране на хардуер, IDE-тата и още много други.

Има и нещо, наречено middleware, което е по средата между тези две „нива“. За пример дават TCP/IP стека.


Аз не бих посмяла да разделя езиците на системни и приложни. C е типичен пример, тъй като има много системен софтуер, изписан на него, но това не означава, че няма както системен софтуер, написан на друг език, така и приложен софтуер, написан на C. За мен system и application са прилагателни за програмите, не за езиците.

За Python - мисля, че на него съвсем спокойно може да пишеш не само приложен, но и системен софтуер. Пример за системен софтуер, написан на Python, би трябвало да е PyPy.

И, накрая, относно Python за новаци - Python е ООП език. Добре е първо да имаш предства за процедурно програмиране с някой подходящ за това език (типични примери май са C, Pascal, Perl също може да мине), а в последствие да се запознаеш с обектно-ориентирания начин на мислене. Лично мое мнение е, че Python има по-хубава ООП парадигма от Java и C++, така че би трябвало да е добър избор за научаване на ООП.

Я дай повече инфо за смоку че не се сещам за какво става въпрос..

Като знам начина на изразяване на go_fire, най-вероятно Смоку е Python, а бъзик е Basic.

Абе и аз така си мислех ама не бях сигурен.. иначе по въпроса кво спорите асеблер си е най-добър  :D

кво спорите

Кой спори?  ???

асеблер

Асе кой? И той хубаво си е най-добър, ама можеш ли да живееш в свят, в който се пише само на асемблер?

И аз да попитам......

'Смоку' това на шопски ли е? ??? ??? ???

И аз да попитам......

'Смоку' това на шопски ли е? ??? ??? ???

На гоу-файърски е.  ;D Той така си приказва, не сте ли му свикнали? ;)

Това хората които пишат на асемблер, доколкото са останали, тяхното им е лесно, като на американците. Имам предвид - американец да си купи примерно БМВ, това си е за престиж. Европеец да си купи някоя голяма американска кола, примно онези големите Додж-ове, ей така щото можел да контролира силата....това си е педалщина и комплексарщина. Та така, същото е и с асемблера :)

Е вие пък .. не казвам ,че пиша само на асемблер но искам да ви кажа че този език, колкото и да е глупав и труден може да се ползва както за направа на програми, така и за операционни системи. Разликата е само 5 асемблерови реда между това да направиш ос и програма. И между другото, вного хора си мислят ,че това е някакъв много труден и загубен език, но всъщност не е така. Като започнеш веднъж , после всичко е лесно. Аз лично се научих първо да пиша на микроконтролери ,а после го приложих и за компютър.
Естествено аз не пиша всичко на асемблер, дори не ми е фаворит ,но просто е много бърз. Любимият ми език всъщност е С++.

Основният проблем с писането на асемблер е че кода не може да се портне за друг процесор, а трябва да се пренаписва изцяло. Не случайно в повечето операционни системи почти няма код на асемблер. Дори и в ffmpeg асемблер се ползва много рядко и е опционален.

Е не, не съм чак толкова голям да го измисля сам. Всъщност си е програмистки жаргон и аз не много отдавна разбрах, че програмистите му викате тъй.

За асемлера. Да хубав си е, спор няма. И да не е труден. Май само езика FUCK има по-малко инструкции, ама и за това не съм сигурен. Проблема му не е в трудността, нито в преносимостта. Проблема му е, че трябва да се пише страшно много код, а това вече не е за всеки гамен. 

Броят на инструкциите зависи изцяло от процесорната архитектура - CISC такава - примерно x86 - има доста, във всеки случай далеч повече отколкото оператори и запазени думи има в езика C. И проблемът с преносимостта си е изначален, не може да пишеш на машинен език и това да е преносимо. Елементарен пример е това да речем:

   0x0000000000400498 <+4>:     mov    0x2003e2(%rip),%edx       
   0x000000000040049e <+10>:    mov    0x2003e0(%rip),%eax       
   0x00000000004004a4 <+16>:    add    %edx,%eax
   0x00000000004004a6 <+18>:    mov    %eax,-0x4(%rbp)
   0x00000000004004a9 <+21>:    mov    -0x4(%rbp),%eax
   0x00000000004004ac <+24>:    mov    %eax,0x2003d2(%rip)       

...и:

00 ALU: ADDR(32) CNT(12) KCACHE0(CB0:0-15) KCACHE1(CB1:0-15)
      0  y: LSHL        ____,  R1.x,  6     
      1  x: ADD_INT     ____,  R0.x,  PV0.y     
      2  w: ADD_INT     ____,  PV1.x,  KC0[6].x     
      3  z: LSHL        ____,  PV2.w,  2     
      4  y: ADD_INT     ____,  KC1[0].x,  PV3.z     
         z: ADD_INT     ____,  KC1[1].x,  PV3.z     
      5  x: LSHR        R2.x,  PV4.y,  2     
         y: LSHR        R0.y,  PV4.z,  2     
         w: LSHR        R0.w,  PV4.y,  2     
01 TEX: ADDR(48) CNT(2)
      6  VFETCH R0.x___, R0.w, fc153  MEGA(4)
         FETCH_TYPE(NO_INDEX_OFFSET)
      7  VFETCH R1.x___, R0.y, fc153  MEGA(4)
         FETCH_TYPE(NO_INDEX_OFFSET)
02 ALU: ADDR(44) CNT(1)
      8  x: ADD_INT     R0.x,  R0.x,  R1.x     
03 MEM_RAT_CACHELESS_STORE_RAW: RAT(11)[R2].x___, R0, ARRAY_SIZE(4)  MARK  VPM

И двете са асемблерен код, който зарежда от два определени адреса в паметта две стойности, събира ги и ги записва обратно в паметта. Едното е за x86, другото е за AMD GPU-та. Няма големи прилики май :) За разлика от това,C кода е почти идентичен.

М-м в грешка съм май, не бях подозирал до какви висини е стигнала CISC последните десетина години, след ерата Котлон/П3. Ама то за туй е форум — да си изправяме кривините едни другиму.

Кода, който gat3way е дал ще работи на всеки 32 или 64 битов x86 процесор.

Абе аз за писане на асемлер ;D ползвам fasm главно щото го има за всички дистрота..

Кода, който gat3way е дал ще работи на всеки 32 или 64 битов x86 процесор.

Нe съм убеден, rip е 64-битовия instruction pointer.

Цитат

   0x00000000004004a6 <+18>:    mov    %eax,-0x4(%rbp)
   0x00000000004004a9 <+21>:    mov    -0x4(%rbp),%eax
   0x00000000004004ac <+24>:    mov    %eax,0x2003d2(%rip)       

offtopic: някаква представа защо компилатора е генерирал първите 2 реда? Струват ми се излишни. Резултата от събирането е в eax, не би ли трябвало да го запише направо в 0x2003d2(%rip)

Без изходния код мога само да гадая, но предполагам при следния случай

GeSHi (C):
int foo(){
  int result = 1+1;
  return result
}

Ще се наложи резултата от 1+1 да го хвърли веднъж в result (BP-4 напр.) и още веднъж към return т.е. EAX
е зависи от това с какво оптимизации е компилирано...

Дам, така е. Все пак втория mov не ми е ясно защо се прави - стойността вече би трябвало да си е в eax.

Нe съм убеден, rip е 64-битовия instruction pointer.

Честно казано не погледнах инструкцията, вдиях че се ползват 32 битовите регистри и реших че ще работи на 32 битов процесор. Silly me  :(

Разбирам ви прекрасно, но за reverse engineering асемблера няма алтернатива  >:D