Anvar aka ancha avval yozilgan bu cli tool uchun chiroyli web interfeys yasab qo'yibtilar. Balkim click egalari ozgina fokus berishsa o'zlarida pesochnitsa sifatida ishga tushirib qo'yishsa ham bo'ladi.

https://github.com/anvarulugov/click-tester-webui/

Ma'lumot o'rnida: Anvar Ulugov qadim-qadim zamonlarda tasix tarmog'ida mashhur bo'lgan ulugov.uz saytlar katalogining muallifi hisoblanadilar. O'z vaqtida tasix doirasida qidiruv va kerakli saytlarni topish uchun eng mashhur loyihalardan biri bo'lgan. Old schoollar yaxshi eslashadi bu loyihani.

Tushunmaganlar:
- Kap-kattta bola yumaloqcha yasab o'tiribti

Tushunganlar:
- Vaov Cda pixelized bo'lmagan progress bar

Hozirda gumanoid robotlar nega kerak degan savolga gumanoid robotni o'zidan javob)

Bazan muhandis sifatida haqiqatni aytgan ham maqul menimcha.

Robotlar odatda turli xil platformalarga ega bo'ladi. Virtual, Real va shunga qarab ulardagi tashqi dunyo bilan bog'lanish metodlari ham turlicha farq qiladi. Lekin ishlab chiqish jarayonida bo'lgan juda ko'plab robotlar uchun hozircha aniq bir usecase mavjud emas.

ARM robotlar OK, ular uchun allaqachon ish ham boshqa narsalar ham qilib bo'lingan. Menimcha keraklicha pikka chiqqa metod u. Lekin qolgan nuqtalarda masalan gumanoidlar hali aniq bir maqsadga ega emas.

Men bu bilan ishlab chiqish jarayonini to'xtatish kerak demoqchi emasman. Inson harakatini takrorlovchi jarayonni qilib boraverish kerak. Ionoskop, giroskop, protsessor va shunga o'xshab ko'plab narsalar aslida inson tanasini o'rganishdan ixtiro qilingan.

Nu agar mindey do'ppini yonga yechib qarasangiz gumanoid robotlar ko'ngil ochishdan boshqa narsaga kerak emas. - Uy ishlarida yordamchi? Deysizmi? Uzrkuya sifatli kofe va kir yuvish mashinasi har qanday robotdan ustun hisoblanadi va mantiqli ham. Droidlar kundalik turmush tarzimizga kirib kelishiga hozircha erta bo'lsa kerak.

Undan ko'ra ular qilishi kerak bo'lgan boshqa sohalar ko'proq.

Tojik tilida birinchi dasturlash tili ishlab chiqildi - SomonScript

Bu yoshlarning dasturlashni ona tilida o'rganishiga imkon beradi.

https://github.com/lindentechde/Somon-Script

@botirziyatov

Nu eng legendasi

https://t.me/nolvabir01/33

Mahallalar kesimida har chorshanba kuni uyiga svet kelmasligiga o'rganib qolgan Eshmat 🫥

Rustdagi bir qator kod Cloudflare tizimini qulatga va jahon internet tarmog'ini izdan chiqishiga sabab bo'lgan. Bugun Rust va C masalasida Sohib (orzklv) bilan bahslashib qolgandik 😄

Rustni xatolarni o'tkazmasligi odatda zo'r, lekin bu ba'zan xalaqit ham beradimikan deyman. C bu "-Hay bolam o'zing bilasan!" deydigan otaga o'xshaydi. Ya'ni xohlagancha xato qilish va eksperiment o'tkazish mumkin. Demak xaklar soni ko'payadi.

Da tan olish kerak cloudflare agar shu qismi C da bo'lganda muammoni xuy topishi ham mumkin edi, lekin boshidan bufer to'lishiga bunaqa xatoni o'tkazib indamay yuborish ehtimoli ham ko'p edi. Odatda C da bu tabiiy refleks bilan qilinadi. Shuningdek yana bir narsani tan olish kerak memory safe yo'qligi sabab ham C bu qismda yutqazadi, ya'ni ko'plab CVElar aynan shu sabab kelib chiqadi.

Ammo eng mininum levelda hardwarega kelganda C yutib chiqaveradi har doim. Masalan Rustni allaqachon linux kernelga integratsiyasini boshlangan. Ammmo nega haligacha bu ekotizm uchun normal Audio yoki USB driver qilinmagan deb o'ylaysiz? Masalan oddiy: C da memory safe yo'qligi driverlarda instalgancha pointer aliasing qilishga imkon beradi, bu esa Rust falsafasiga zid. Ya'ni MMIO bilan ishlashda Rust haddan tashqari talab qo'yib cheklab yuboradi. C esa shunchaki to'g'ridan to'g'ri registerni ko'rsatish va unga yozishga imkon beradi. Bu esa datasheetga qarab ortiqcha harakatlarsiz bemalol driver yozishni taminlaydi. Oddiy misol hardware bilan interrupt handler qilib ko'rishni Rust hozircha eplay olmaydi, aniqrog'i qiladi ammo 90% kodingiz jarayon xavfliligini tekshirishdan iborat bo'ladi. Ya'ni bunaqa keyslar aslida real memory emas to'laqonli mapping hisoblanadi. Bu esa o'z navbatida Rust bozirini microcontrollerdan ham chiqarib yuboradi. ABI masalasi ham xuddi shunday, C ustida turipti.

https://blog.cloudflare.com/18-november-2025-outage/

🔸 Masalan registerga murojaat qilish:

C:

volatile uint8_t *PORTB = (volatile uint8_t*)0x25; 

Rust:

const PORTB: *mut u8 = 0x25 as *mut u8;

unsafe {
    let v = core::ptr::read_volatile(PORTB);
    core::ptr::write_volatile(PORTB, v ^ (1 << 0));
}

ℹ️ Bunda har ikkisida ham bir xil natija bo'ladi, ammo build jarayoni murakkab.

-----------

🔸 I/O portlar bilan ishlash

C:

uint8_t *p = (uint8_t*)0x25;
uint8_t a = *p;
uint8_t b = *p;

Rust:

let a = unsafe { *port };
let b = unsafe { *port };

C ASM:

in   r24, 0x25
mov  r25, r24 

Rust asm:

ld   r24, (0x25)
ld   r25, (0x25)

ℹ️ E'tibor qilgan bo'lsangiz C va Rustda ham ikkita instruksiya, ammo C da bitta load. Ya'ni portni bir marta ochib keyin registerdan ovolyapti xolos. Demak yuklama oshishni boshladi.

-----------

🔸 Looplar:

C:

for (i=0; i<8; i++)
    sum += buf[i];

Rust:

for i in 0..8 {
    sum += buf[i];
}

C ASM:

    ld   r18, X+
    add  r24, r18

    ld   r18, X+
    add  r24, r18

    ld   r18, X+
    add  r24, r18

    ld   r18, X+
    add  r24, r18

    ld   r18, X+
    add  r24, r18

    ld   r18, X+
    add  r24, r18

    ld   r18, X+ 
    add  r24, r18

    ld   r18, X+ 
    add  r24, r18

Rust:

loop_start:

    cpi   r16, 8
    brge  panic

    movw  r30, r20
    add   r30, r16
    adc   r31, r1
    ld    r18, Z
    add   r24, r18

    inc   r16
    rjmp  loop_start

ℹ️ Cda unroll bilan 16 instruksiya, Rustda bo'lsa 72ta instruksiya. Ya'ni bound check + loop overhead qo'shilyapti.

Interruptlardagi farqlar.

C:

sbic 0x05, 0
sbi  0x05, 0
reti

Rust:

__vector_11:
    push r24
    push r25
    lds  r24, 0x25
    eor  r24, 1
    sts  0x25, r24
    pop  r25
    pop  r24
    reti

Rustda yozilgan kodda tugmani bossangiz CPU hayot falsafasi haqida o'ylashni boshlaydi. ISR uchun esa bu narsa hech qachon kerak emas. ISR har doim maksimal optimizatsiya berishi kerak. Yana bir narsaga e'tibor qilgan bo'lsangiz rust port ma'lumotini sramga ( sts 0x25, r24) ham yuklab olyapti. Ya'ni boyagi registerga yozish masalasining yana bir tasirini shuyerda ko'rish mumkin. Rust i/o ni mapping qila olmasdan uni LDS sifatida ko'ryapti.

Lekin bu C zo'r, Rust xuynya degani emas. Har ikki tilning o'z o'rni va vazifasi bor. O'ziga yarasha qulayliklari va kamchiliklari ham.

Yuqorida Cda bor kamchilik rustdan ustunlik beryapti. Lekin buni xavfsizlik jihatidan qaralsa optimal emas bu.

Masalan nginx dahshatli darajada optimized ishlaydi. Ammo har bayram bitta cve bor. Shu sababli ham katta kompaniyalar proxylari uchun rustdan foydalanishadi. Ularga buyerda resursdan ko'ra xavfsizlik muhim. Rust esa bunda ustun.

Savol tug‘iladi: interruptlar nega kerak o‘zi?

Avvalo boshqa savolga javob topib olsak. Bu shayton mexanizm nima? Interrupt bu protsessorning hozir bajarayotgan ishini vaqtincha to‘xtatib, muhimroq voqeaga (signalga) e’tibor berish imkonini beradigan mexanizm.

Ho‘sh, bu nega kerak? Odatda markaziy protsessor tezligi juda katta bo‘ladi. Masalan, 1 GHz lik protsessor nazariy jihatdan 32 bitlik shinada 32 Gbit/s ma’lumot uzatish tezligiga ega, ya’ni soniyasiga 4 GB ma’lumot almasha oladi. Albatta buyerda oksidlanish, o‘tkazgichlar materiali yanada o‘z tasirini beradi. Aslida oltin ishlatilishi sababi ham shundan, maktab fizikasidan bizga ma’lumki oltin juda katta o‘tkazuvchanlik xususiyatiga ega.

Endi buni USB va printer misolida ko‘ramiz. USB 2.0 ning amaliy tezligi taxminan 25 MB/s atrofida. O‘rtacha printerlar daqiqasiga 30 ta sahifa chop eta oladi, bu esa tahminan har bir sahifa uchun 2 soniya degani. Agar siz 5 sahifadan iborat faylni chop etishga bossangiz, printer uni taxminan 10 soniyada chiqarib beradi.

Bu jarayonda nimalar bo‘ladi? Dastur hujjatni printer driveri orqali spoolerga yuboradi, spooler esa bu ma’lumotni diskda/navbatda saqlaydi. Keyin kerak paytda ma’lumot RAM -> USB buffer -> printer yo‘lini bosib o‘tadi. Texnik jihatdan kompyuter bu ma’lumotni printerning buferiga juda tez yuborishi mumkin, lekin dastur va driverga "sahifa tugadimi?", "keyingi sahifani yuboraymi?", "avvalgi sahifaning statusi nima bo‘ldi?" degan savollarni hal qilish kerak bo‘ladi.

Agar bu ish interruptsiz, faqat polling bilan qilinsa, CPU doimiy ravishda printerni tekshiradigan cheksiz loopga tushib qoladi. U faqat shunaqa ish bilan band bo‘ladi: "tayyormisan?", "tayyormisan?", "tayyormisan?" va o‘zining qimmatli taktlari va vaqtini shunga sarflaydi. Masalan, 1 GHz protsessor va 10 soniya davom etadigan chop jarayoni uchun bizda 10 milliard takt bor. Agar bu taktlar faqat printerni kutishga sarflansa, bu vaqt ichida assembler darajasidagi juda katta hajmdagi kodni bajarish mumkin bo‘lardi. Shunchaki, tasavvur uchun aytganda, Super Mario o‘yini hisob-kitobiga yetadigan resursni printer uchun bekorga yeb qo‘ygan bo‘lamiz.

Shunday kutish jarayonlarini optimallashtirish uchun interruptlar kerak. Interruptlar bo‘lsa, CPU printerni ishga tushiradi, ma’lumotni yuboradi va keyin taktlarini boshqa ishlarga sarflab turadi. Printer esa o‘zining ichki dasturi va apparat qismida sekin-asta sahifalarni bosadi. Ish tugagach, printer yoki USB kontrolleri protsessorga:
- Hey, birad, men ishimni qilib bo‘ldim, degan ma’noda interrupt signali yuboradi. CPU hozirgi ishini vaqtincha to‘xtatib, shu interruptni qisqacha qayta ishlaydi (statusni yangilaydi, navbatdagi sahifani yuboradi va hokazo) va yana o‘zining asosiy ishiga qaytadi.

Natijada: Printer tezligi o‘zgarmaydi (baribir 30 sahifa/minut atrofida), Lekin CPU bo‘sh turgan o‘rniga, milliardlab taktlardan boshqa foydali ishlar uchun foydalanadi.

Ammo shuni unutmaslik kerakki interuptlar doim ham foydali ishlamaydi. Masalan har bir interupt uchun CPU uning joriy holatini saqlab borishi kerak, interuptni bajarishi va holatini qayta tiklashi kerak. Me’yordan oshsa overhead degani. Ba’zan interrupt storm kabi holatlar ham kuzatiladi, bunda interuptga cheksiz ma’lumotlar kelib tizimni sekinlashtirib yuboradi. Shuningdek interupt hardware qatlamda muhim bo‘lgani uchun agar bunga dasturiy qismmda past prioritetli task yuklangan bo‘lsa, protsessor boshqa yuqori prioritetli taskni bloklab turishi mumkin.

@yetimdasturchi

C dagi lo‘licha usullardan real hayotdagi misollar:

Masalan Linuxdagi static key / jump label mexanizmini olaylik. Bu qism performance-critical koddan if (flag) degan oddiy tekshiruvni ham olib tashlash uchun xizmat qiladi. Ya’ni fast-pathda 0 ta branch, 0 ta load, 0 ta condition faqat bitta NOP bo‘lishini ta’minlaydi.

if (trace_enabled)
    do_trace();

#define JUMP_TABLE_ENTRY(key, label)            \
    ".pushsection   __jump_table, \"aw\"\n\t"   \
    ".align     3\n\t"              \
    ".long      1b - ., " label " - .\n\t"  \
    ".quad      " key " - .\n\t"        \
    ".popsection\n\t"

/* This macro is also expanded on the Rust side. */
#define ARCH_STATIC_BRANCH_ASM(key, label)      \
    "1: nop\n\t"                \
    JUMP_TABLE_ENTRY(key, label)

Agar bu ishni to‘g‘ridan to‘g‘ri qilinsa trace_enabledni tekshirish uchun har safar memory access, CPU pipeline va cachega yuklama tushirish kerak bo‘ladi. Flag ko‘tarilganini tekshirish, predictorni ishga tushirish kerak. Ya’ni har safar load, compare, branch amalga oshirish kerak.

Endi tasavvur qilaylik net stackda 100Gbit ma’lumot kelmoqda.

100000000000 bit/s / (64 * 8) bit = 195 million paket / sekund. Ya’ni sekundiga deyarli 200 million marta if caseni tekshirish kerak. Oddiy dastur sintatsisida 1 qator kod, ammo CPU uchun bu uchta operatsiya degani.

Demak biz oddiy keysda debuggerni har bir paket uchun yoniq yoki o‘chiq ekanini tekshirmoqchi bo‘lsak predictor 99% holat uchun false tanib oladi. Agar qayerdadir ture kelsa predictor pipelineda branch misprediction qiladi va CPUda bularning har 15-20 sikl tiklanadi. Xullas odatiy CPUning yarim resursini patchi shu if caseni tekshirishga sarflab qo‘yish mumkin.

Endi kernel levelda bunday millionlab jarayonlarni miyyangizga sig'dirib ko'ring.

Buni nega Rustda qilish gemoroy? Rust endi-endi asm gotoni qo‘llashni boshlayapti. Shuningdek rustda control-flow graphni label asosida manipulatsiya qila olmaydi. C esa bunga bilganingni qil deydi. Shuningdek compile qilingan taqdirda ham memory safe sabab runtimeda bu jarayonni patch qilib bo‘lmaydi, kod segment read only, yuqoridagi jarayon esa rust falsafasiga zid hisoblanadi. Shu sababli ham yuqoridagi keysni Rust, C dan chaqirib ishlatadi.

Buyerda aslida til imkoniyati emas falsafalar to'qashuvi bor. Rustning memory masalasida o'z falsadasi bor. C da esa pointer, struct, alignment kabi jarayonlar asm bilan bir xil modelda qurilgan. Imkoniyat katta, xato qilish ehtimoli ham katta degani. Ammo bu xatolardan voz kechib ham bo'lmaydi. Chunki ular boshqa xatoliklar oldini olish uchun ham kerak.

Keyin bir ma'lumot asm goto faqat C va C++da mavjud. Boshqa tillardagi siz ko'radigan gotolar bu o'sha til doirasidagina kerakli labelga o'tadi xolos (semantikani buzmaydi). Cda esa bu jarayon CPU darajasida sakrashga imkon beradi.