Ja mislim da se dilema moze rjesiti gledanjem oglasa za posao u IT oblasti.

svako o onome sto mu treba, ako priupitas ove u bankama "najveca je potraznja za cobol programerima a nema ih nigde", realno treba im 2 coveka za celu jugu i treci ne bi imao posla, sad sto ne mogu da nadju ni ta dva ne znaci da je trka za kobol programere ... toj firmi treba asm covek i ne mogu da ga nadju (verovatno ne za te pare koje nude) pa je po njima frka za asm ... ja mogu iz mog ugla da ti kazem da trenutno ne postoje konsultanti za mccge i da je to danas najtrazeniji posao na svetu (evo trazimo da zaposlimo par komada vec 2 godine i nema nijednog) tako da .. ako pricamo o tome sta se stvarno trazi i koristi, sto rece kolega odin, pogledamo oglase ... to sto za projekat od 30 dana treba covek kog ne mogu da nadju ne znaci nista (da ne spominjem da asm programera za mcu ima dosta, i to dobrih ima cak vise nego C programera za mcu)

Slazem se sa kolegama, to je bila ne previse relevantna izjava.
Takodje nema ozbiljan HR konsulting u toj oblasti oko embeded programiranja, za IT i nekako vec ima ali uglavnom za neke WEB poslove.

Silom prilika sam bio prinudjen ovih dana da potrazim nov posao u IT (predhodni poslodavac zatarabio) i na srecu sam nasao nekoliko ponuda o kojima jos uvek razmisljam.
Volim i ja embeded programiranje ali kako stvari stoje imao bih silne muke da nadjem posao za to. Mislim da je razlika u ponudi poslova kod nas izmedju embeded i IT (web) 1:100 ako ne i vise, a za ASM vs C/C++ jos mnogo manja.

Druga stvar oko embeded programiranja, gledam bas sad nesto detaljno oko Cortex M3/M4 programiranja, razvojni alati su poslednjih godina kao i sama MCU jezgra toliko napredovala da ASM NIJE vise obavezan, tj prakticno veoma veliki deo programa moze da se napise direktno u C bez gubljenja perfomansi.
Kod ARM jezgra se sad navodi u specifikaciji a i stvarno je tako da su optimizovana za programiranje u C jeziku sto znaci da gro (ne sve) ASM komandi imaju 1:1 zamenu u C.
Eventualno one komande koje nemaju direktnu 1:1 zamenu, u prakticnoj nekoj primeni ekvivalenti C funkcija prave istu stvar u ASM koji bi inace morao da iskuckas u ASM za postizanje neke funkionalnosti tako da se opet svodi na isto.
Sve u svemu jako su se priblizili sa preformansama programa pisanih u ASM i C u nekoj PRAKTICNOJ implementaciji tako da je realno vrlo malo potrebe ima programirati u ASM kada imamo C sa svim svojim prednostima.
Dakle ovo je bilo za ARM, mozda je drugacija situacija (ne znam tacno) za neke druge MCU/CPU ali mislim da je i kod ostalih vrlo slicna situacija.

Ko ce ga znati nasta je taj gospodin tacno mislio kada je dao tu izjavu ali ovo gore sto sam napisao jos vise "potkopava" tu izjavu.

_{[Ovu poruku je menjao mikikg dana 07.01.2014. u 18:57 GMT+1]}

Ne, ne radi se o šefu računskog centra banke, el. distribucije ili neke druge institucije. Skup je predstavljen kao naučni.

Čovek jeste rekao da se u kvantitativnom smislu najviše traže programeri IT, i da je tu potražnja veća od ponude, i da ima posla.

Spornu rečenicu je izgovorio na kraju tog kratkog intervjua.
U kvantitativnom smislu nije potražnja za programerima u asembleru ni približna kao za IT, ali je rekao da je odnos ponude i potražnje mnogo veći zbog nedostatka programera u asembleru.

Evo ja sada radim deo softvera za jednu firmu koja ima desetak programera. Rade sa 8052 u C-u. Ja treba da im napišem neke drajvere za neki uređaj koji je sličan bankomatima, ali nije to. Imaju dobro razrađen sistem pisanja softvera, nisam video bolji. Nekada su pisali softver i na asembleru, ali ti inženjeri su ih napustili, dok su novodošli odmah počeli sa C-om.

Nije da ne znaju asembler, napišu po neki makro na asembleru sa par MOV instrukcija i to je to. Ali korišćenje steka im je nepoznanica, toga nema u C-u, i uopšte tehnike programiranja u asembleru.

Nije sporno da treba ponekada napisati nešto ozbiljnije i na asembleru, ali sporna rečenica mi sugeriše da je previše ljudi otišlo ka višim programskim jezicima, a da malo njih zna da piše kvalitetno delove softvera na asembleru. Nisam ni slutio da je napravljen toliki disbalans.

E, da vidiš kakvih sve naučnika ima po akademskim institucijama, i kakve sve "naučne" skupove oni održavaju, zaprepastio bi se.





Valjda je jedan od prvih koraka prilikom učenja C-a, kako, kada i zašto koristiti i kako iskoristiti stek i šta je to i čemu služi PUSH BP; MOV BP, SP; tako da nepoznanica korišćenja steka više govori o tim programerima, nego o C-u. Moje mišljenje je da onaj ko zna da programira u C-u na niskom nivou, može bez ikakvih problema za relativno kratko vreme početi efikasno da kodira u asembleru.

da nisi mislio na neke C# programere? ja nisam jos upoznao C programera koji ne zna sta je stek i kako se istim manipulise i to u normalnom "desktop" programiranju, u embedded svetu bez poznavanja kako sljaka stek ne mozes da programiras ni za pic ni za atmel a kamoli za motorolu ili arm ili .. tako da nesto ne bih rekao da je rec o "programerima" .. svaki senior c programer moze da cuka bilo koji asm posle 3 dana citanja dokumentacije...

a o disbalansu za koji pricas, evo ti bas sam u novembru pricao nesto sa kolegama, u celom dev+support+consulting timu samo jedna indijka ne zna asm, svi ostali znaju asm za intel i skoro svi (oko 80%) znaju asm za motorolu, oko 60% znaju asm za mips i spark ...

inace, ASM se i dalje trazi ... ja da hocu da vodim firmu koja radi embedded ne bi zaposlio nijednog programera koji ne zna ASM a svi bi cukali 99% vremena C .. daleko od toga da ASM "ne treba", no ta izjava je prosto cista glupost, prvo zato sto 99% C embedded programera ZNA C, drugo zato sto je to inace toliko mala nisa da je bilo sta od "potrebe" u istoj nisi abitno za bilo kakvo univerzalno izjavljivanje bilo cega ... ocigledno je njima trebao asm programer da im nesto odradi i nisu mogli da urade pa su pod utiskom izjavili tu, slobodno mogu reci, glupost.

inace skoro mi posla drugar bas ovde sa foruma, neka poredjenja asm/C/optimised C .. za neke cesto koristene algorigme, doduse to vise govori o tome koliko im je los taj c kompajler (posto razlika izmedju njihovog optimised C i C resenja ne bi smela da bude uopste mnogo razlicita, njihov kompajler to ocigledno nije umeo da optimizuje)

btw koga zanima ceo tekst: http://www.dspconcepts.com/sit...DSP%20vs%20Micro%20rev%202.pdf

Bogdane, nisu svi kao ti.

šta misliš kakvi inženjeri danas izlaze sa naših fakulteta. Zatim tu je i faktor mogućnosti nalaženja posla.

A kada imaš gazdu koji se zalepio za neki stari mikrokontroler i misli da je KEIL svemoguć, onda eto problema za zapošljene.

Što se tiče ARM jezgra, za njega je malo teže napisati nešto na asembleru što bi bilo efikasnije od koda koji generiše dobar kompajler nekog višeg programskog jezika. Obilje registara i najbolja osobina vertikalnosti skupa asm naredbi olakšava pisanje dobrog kompajlera. Tu nema mesta trikovima u asembleru, jer neka funkcija se može efikasno napisati samo na jedan način.

Ali kada mušterija neće da odustane od svog arhaičnog mikrokontrolera, iako sam mu nudio da sa SilLabs familijom uradimo drajver na C-u, onda ‚‚veži konja gde ti gazda kaže‚‚

Pozdrav svima.

(doc koji sam linkovao bas pokazuje kako je ASM izvedba mnooogo brza, i
prilicno pokazuje kako je koristeni C kompajler limitiran)

ma vidi, ne mislim ja ni da su svi koji izadju sa faksa upotrebljivi ni
da su sve gazde pametne, ono sto kazem je da je lik koji je izjavio tu
recenicu "u tom trenutku imao taj problem" pa su mu asm programeri bili
najpotrebniji... realno je kvalitetnog kadra u srbistanu manjak za sta
god da se uhvatis, od kvalitetnih strugara preko kvalitnih stolara,
kvalitetnih inzenjera ili kvalitetnih vodoinstalatera .. sve go retard
do retarda, tako da sta god da trazis kvalitetno neces naci, ili ces
naci jako tesko, tako da sta god da ti je u tom trenutku potrebno, toga
najvise fali...

Kom "asembleru"? Za koju arhitekturu? Za mikro-optimizaciju postojećeg koda, za pisanje novih aplikacija, za pravljenje kompajlera? Za embedded uređaje ili za pisanje x86 bootloadera? Mislim da su razlike veoma bitne.
Sa unapređenim performansama mnogih platformi i smanjenom potrošnjom, ovih dana teško da puno njih baš želi da ima posla sa njakanjem 100% asemblerskog koda osim ako se to baš ne isplati. Većina je spremna na moguća usporavanja prilikom korišćenja viših jezika zarad lakšeg razvoja i radije samo povremeno beže u ASM svet sa inline ASM funkcijama u C, stoga nisam toliko siguran da je potražnja velika.

Sa druge strane, smatram da dobar programer mora da zna šta se desi kada pripuši F5 ili ukuca "gcc", tj. kakve se instrukcije šalju u pravcu procesora i šta se to zapravo dešava ispod haube.

@bogdan.kecman

Kojoj to banci u Srbiji trebaju Cobol programeri i za koje namene tacno?

U odredjenim slucajevima (obrada signala, video kodiranje i sl..) je moguce i dalje dodatno ubrzati ARM kod uz pomoc rucno pisanog asemblera tipa NEON optimizacija.

Medjutim, to je vrlo ogranicena primena koja se svodi na eventualnu optimizaciju nekih rutina (tipa filtera / transformacija za audio ili transformacija ili predvidjanja pokreta u video kodiranju) dok za ostalih 90% koda stoji sto je korak napisao tj. to nema nikakvog smisla i C/C++ kompajler ce tih 90% koda pretvoriti u podjednako brz (a mozda cak i brzi) masinski kod uz drasticno manje ulozenog programerskog vremena za razvoj.

Obicno su eksperti koji znaju da optimizuju koristeci ARM ili Intel asembler vec i ovako i onako senior sw. inzenjeri sa velikim iskustvom u dizajnu i optimizaciji softvera i nisu jeftini zato sto nisu ni toliko laki za nalazenje (ne nuzno zbog toga sto ih nema puno vec zato sto vrlo verovatno vec imaju dobro placen posao).

potpuno povezano sa temom ubilo se :D no ajde, prosle godine, socgen trazila za 2 projekta coveka, dovukli coveka iz svedske, reifeissen trazila coveka, dosao nemac, PwC trazio ljude prosle godine, pretprosle godine i godinu pre toga, izmenjali se neki rumuni i bugari.... sta su tacno radili "nem'pojma" (za pwc su mi rekli da vise ne daju lokalno oglas posto znaju neke lokalce koji "znaju" cobol ali nisu njima zadovoljni, za ove ostale znam preko nemacke konsalting kuce preko koje su zavrsavali te projekte i trazili ljude, takodje 2 recruitment agencije ovde u srbistanu su me dosta puta zadnjih 5 godina zvale da pitaju dal slucajno ocu radim neki kobol, nisu rekli za koga uglavnom no bio je 2 puta u pitanju filip moris, nemam ideju sta im je na kobolu al trazili su part time coveka 2 puta da ja znam)


@ivan, korak je u osnovi asm programer a mi ga smaramo sa C-om godinama, cak je napravio i svoju verziju asemblera za motorolu.. ovakve izjave (kako je asm i dalje trazen a nema ga nigde) mu prirastu k'srcu :D .. imali smo vec dosta price oko toga kako je "ceo kod" pisati u asm-u neisplativo danas cak i za ogromne serije ...

e sad, ono sto je stvarno porazavajuce je ovaj doc koji sam zakacio, primer je necega sto bi kompajler trebalo da optimizuje - a to ne uradi

E, ovaj poslednji deo je prava slika stanja. Ima nas koji znamo ali...

da, ako prevedemo taj zahtev u "jako su trazeni asm programeri koji hoce
da rade za kikiriki a nigde ih nema" onda je vrlo tacna :) .. nevezano
za elektroniku, ja sam od 2000 na ovamo mnoooogo stranih "investitora"
sreo koji si dosli u srbistan da "uloze pare" da bi pobegli odavde jer
"ovde nema to sto im je receno da je ovde dostupno u izoblju", gde je
"to" - ultra jeftina extra strucna radna snaga .. kazu ima jeftina
nestrucna i ima strucna ali skupa radna snaga, ali kombinacija jeftina +
strucna -> jok

neke poslove za koje je potrebno fizicko prisustvo jos i mogu da nadju
(nekoga ko ce da sedi u kancelariji i lemi rucno 8h dnevno za par
stotina nemaca npr) ali bilo koji posao koji moze da se radi remote,
zasto bi programer radio za 300e (koliko mu takvi "investitori" nude i
kukaju kako nema radne snage za xyz) ako moze za istog tog investitora
da radi od kuce za 3000e

nije za ovu temu ali ovi retardi od lopo^?^?^?^?nasih politicara idu kao
pricaju sa stranim firmama i tamo iznose kako kod nas moze da se dobije
senior developer za 500eur, i kako ce sa tom platom isti da bude extra
srecan i kako toga kod nas ima koliko hoces, kako imamo elektro i
masinske inzenjere sa 20+ godina iskustva koji ce da rade 40h nedeljno
za 100eur i te fore .. znam jednu firmu koja je bila zainteresovana u
indjiji da pravi veliki call centar za neki support, nije to neki high
level tech job ali zahteva znanje engleskog, koristenje racunara ....
oni su ocekivali da ih jedno radno mesto (prostor + struja + komunalije
+ racunar + plata radnika sa svim porezima, dakle bruto) kosta 250$
mesecno, to je bre ljudi 185eura, to da je samo bruto plata pa to je
ispod 100eur mesecno, oni su mislili da ce u to da im udju i prostor i
struja i .. tj. nisu oni "mislili", neko odavde im je to tako predstavio

Taj "investitor", koji je mogao u tako nesto da poveruje (za bilo koju zemlju), je veca ovca od mnogo toga.

Pre ce biti da su se udruzili sa nekim da pokupe subvencije.
Kakav crni investitor da poveruje u price politicara "neke tamo zzemlje".

kao sto rekoh, nije prica za ovde (obzirom da za te pare mogu da se
nadju ljudi u nekim delovima sveta, ja sam support inzenjere za sat
provajdera npr placao 100$ mesecno i bili su srecni ko kucici a ceo
office za 10 ljudi sa netom, strujom, vodom, cistacicom... me kostao
150$, svi zaposleni su bili fakultetski obrazovani i znali su engleski +
ruski + ukrainski)

Bogdane, u vezi optimizacija C kompajlera, mogu da ti kazem da vektorizovanje
skalarnog algoritma nijedan C kompajler ne moze da uradi kako treba. A to je zato sto ne vektorski
algoritam nije lako pretvoriti u vektorski. Zbog toga postoje instrinsic funckije
za SIMD koje onda programer koristi i napise sam vektorizovan algoritam.

@branimir, na zalost, znam ... no ima mnogo toga sto kompajler moze da uradi, posebno kada su filteri u pitanju a sto ne radi, tj ne rade svi .. neke od optimizacija su patentirane (pa ih recimo nema u gcc a ima u vs) a neke prosto nisu implementirane iako su fraj .. gcc vecinu optimizacija koje ima su donacije od par matorih doktora a brdo ovih kompajlera je samo dobudzeni gcc :(, meni vise smeta ne koristenje mcu specific stvari, poput nekih extra registara, nekih extra (npr dsp) asm instrukcija i slicno .. znam ja kako to da zaobidjem ali .. nije isto

gcc se konstantno razvija i dopunjuje novim optimizacijama, računajući tu uzgred i optimizacije koje pišu naši inženjeri (koji nisu ni matori ni doktori - provereno).
Što se autovektorizacije tiče, predlažem da pratite vrlo aktivni razvoj podrške za to u alatu LLVM.

rekoh "vecinu", ne "sve" :)

llvm sam pratio neko vreme ali ne vise, iskreno, previse zanimljivih projekata, premalo vremena :(

sa autovektorizacijom sam imao direktnog kontakta samo kod intelovog kompajlera i tu znam da su kolege nabasale na par bagova (mislim da je jedan kolega bas za autovektorizaciju za intel kompajler pisao patch) no ni sa tim vise nemam kontakt, mislim da smo batalili intelov kompajler za regularne bildove, dal je to nesto oracle menjao kad nas je kupio ili .. nebitno za pricu ..

elem vidim da je lepo dokumentovano (link) pa cu da pogledam kad ukradem koji minut :D hvala za hint .. no ono gde je meni ozbiljna optimizacija interesantna su bas ovi embedded sistemi, 8bitni i 16bitni mikrokontroleri, malo rama, malo flash-a, specificni pipeline, specificne instrukcije (fpu, dsp ..) i slicno .. za "velike" masine i sistemski sw su problemi potpuno drugaciji, tamo par kilobajta overhead-a vrlo cesto ne pravi razliku, ovde par desetina bajtova moze da bude break or make scenario ..

da li je llvm podrzao neki mcu core? znam da je dugo sdcc bilo jedino skroz oss resenje kada je c u pitanju (ne racunam razne basice, paskale i jal-ove) ali nije bio bas stabilan ...

manny, autovektorizacija je slaba vajda kada treba promeniti algoritam. A vektorizacija
upravo to zahteva. Kompajliram llvm/clang svakog petka i jos nisam primetio
neki break through u vezi oog kompajlera i autovektorizacije.
gcc isto to ima jos pre llvm-a ali i to je definitivno ograniceno.
Kompajler jednostavno ne moze dobiti ideje koje ima programer te zato intrinsics
ipak resavaju ove probleme, ako bas neko nece asembler.

bogdane, kod mikrokontrolera sve zavisi. Ako se ne radi o vektorizaciji
obican C kompajler ce zavrsiti posao. Ovaj primer sto si poslao to nije ;)
u svakom slucaju uvek je tradeoff size/speed. Zavisi sta treba.

taj primer je samo primer da "po nesto moze da se isplati u asm-u", ja inace ne cukam cist asm negde od 1994 godine :D

sto se kompajlera tice, ono sto ja vidim kao osnovni problem nisu ti nedostaci optimizacija (koji npr postoje u VC a ne postoje u GCC i slicno) vec kompletn ignorisanje celih komada specijalizovanog hw-a poput FPU ili DSP unita a sto proizvodjaci poklope time sto isporuce dobar broj bibiloteka (pisanih u asm-u) koje onda koristis iz C-a ..

sto se tice ostalih "nedostataka" .. moze tu da se prica do prekosutra no tu je vec varijanta "zasuci rukave" :D .. meni licno na mcu prici mnogo fali namespace "funkcionalnost" C-a .. evo bas sam neki dan portovao neku biblioteku sa atmela (c++) na mcp (c) i nije to preterano ruzno ali umesto da kao na atmelu imam objekat = new XXX; objekat.kalakurcija(); ja imam brdo funkcija XXX_konstruktor(); XXX_kalakurcija_sa_parametrimax(); XXX_kalakurcija_sa_parametrimay(); ... i sad se razmisljam da iskoristim gcc-ov c++ preprocesor samo da mi odradi konverziju c++ -> c i da to nekako spakujem ...

Drugari, vidim oduzila se ova tema, pa da dam i ja moj skromni osvrt na istu,

NOVO VREME:
dakle, potraznja za "asm programerima" (sta god to znacilo) nije bas preterano velika,
ali,
potraznja programera za namenske embedded sisteme postoji. To bi trebalo da znaci,
pre svega poznavanje arhitekture sistema koji treba da programirate, a tek onda i
samog "alata" - bio to C, C++, ASM ili nesto trece (odnosno cetvrto). Vecina ozbiljnih
"igraca" na polju mikrokontrolera ima jako optimizovane kompajlere, gde se samo
jako, jako specificne stvari optimizuju u "ASM". Na primer, razvijanje velikih for petlji
za rad na obradi bitmapa,videa ili muzike, veliki memcopy sa specificnim rotacijama, gralloc
implementacija za target platformu (hardver) i slicno. Ali ovo su veoma, veoma retke situacije,
i one su uglavnom one-shot, znaci urade se jedared, a onda se na visim nivoima sve postize c-om.
Slucajno (ili ne) licno sam radio i na tim optimizacijama, pa je kod mene to uobicajeno, ali,
ono sto mi radimo radimo za Amere i UK, ali je veoma specijalizovano. Retko koji "normalni-
every day usage" embedded developeri ce imati potrebu da se srecu/bakcu sa ovime.


ISTORIJA:
U mojim eksperimentima, bilo je slucajeva kada se morao koristiti asm, na primer, za jedan posao
smo imali porudzbinu od 120k namenskih ploca sa malim "ne tako optimizovanim c kompajler" 8-bitnim mcu,
gde je razlika na kontrolerima sa x i x+1 memorije bila reda "samo" 0.28e - "Do the maths" da li nam se
isplatilo da se nekako uchachkamo/optimizujemo u manje flasha :)

ukoliko nekome treba kobol programmer neka se javi... moj stric je programmer I zna kobol. radio u beobanci I tehnohemiji kao programmer za transakcije... vise detalja privatno

Pozdrav svima! - nisam pokrenuo novu temu iz razloga sto mislim da pitanje koje postavljam ima veze sa ovom temom ili se bar nadam da je tako . Dakle skinuo sam i instalirao mplab/ide verziju 8.10 i pokusao sam da kompailiram iz assamblera u hex- cod , pratio sam upustva iz tutorijala sa sledeceg linka https://www.youtube.com/watch?v=D9ghkyLe7pI , dakle sve odradim tako u pitanju je pic 16f877 medjutim na kraju mi ne konvertuje nista vec prijavljuje sledecu gresku :


Debug build of project `C:\Documents and Settings\nenad\Desktop\nesa.mcp' started.
Preprocessor symbol `__DEBUG' is defined.
Fri Oct 31 14:29:07 2014
----------------------------------------------------------------------
Make: The target "C:\Documents and Settings\nenad\Desktop\MAGGY710.o" is out of date.
Executing: "C:\Program Files\Microchip\MPASM Suite\MPASMWIN.exe" /q /p16F877 "MAGGY710.ASM" /l"MAGGY710.lst" /e"MAGGY710.err" /d__DEBUG=1
Halting build on first failure as requested.
----------------------------------------------------------------------
Debug build of project `C:\Documents and Settings\nenad\Desktop\nesa.mcp' failed.
Preprocessor symbol `__DEBUG' is defined.
Fri Oct 31 14:29:08 2014
----------------------------------------------------------------------
BUILD FAILED
zasto tako moze li mi neko pomoci ?