Hollosi Information eXchange /HIX/
HIX CODER 34
Copyright (C) HIX
1998-02-26
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
1 Re: Instr.ciklusok... (mind)  37 sor     (cikkei)
2 Re: meg mindig karakterfelismeres (mind)  83 sor     (cikkei)
3 Re: prog irasi tanacstalansag [UNIX] (mind)  26 sor     (cikkei)
4 Blinker (mind)  11 sor     (cikkei)
5 Visual Foxpro 3.5 (mind)  8 sor     (cikkei)
6 Masolasvedelem demo (mind)  33 sor     (cikkei)
7 ASPI felulet programozasa? (mind)  14 sor     (cikkei)
8 Delphi levelezolista (mind)  12 sor     (cikkei)
9 Programmer's Oasis (mind)  14 sor     (cikkei)
10 Karakterfelismeres (mind)  30 sor     (cikkei)
11 Karakterfelismeres 2 (mind)  33 sor     (cikkei)
12 Karakterfelismeres 3 (mind)  23 sor     (cikkei)

+ - Re: Instr.ciklusok... (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok!
> =======================================================
> Felado :  [Hungary]
> Temakor: Re: Instr.ciklusok... ( 18 sor )
> Idopont: Tue Feb 24 17:50:34 EST 1998 CODER #33
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
A Pentiumra irt programok assemby szintu optimalizalasanak a
kulcsa: minnel egyszerubb utasitasokkal kell dolgozni.

Oka:
A Pentium csak az egyszeru utasitasokat tudja pipe-olni, azaz
egyszerre egy idoben tobbet vegrehajtani. Termeszetesen csak akkor ha
nincs az utasitasok kozott adatfuggoseg. (Read After Write-> ez a
leggyakoribb)
A RAW-ok esetet csokkenteni lehet, ha a kodot szetkened, azaz a
logikailag egymas utan kovetkezo utasitasok kozott probalsz valami
mast csinalni.
A gyorsasag kedveert a repnz utasitast ugy ahogy van el kell
felejteni. Sokkal gyorsabb ha dec, jnz-vel szervezed meg a ciklust
meg akkor is ha rendszeresen menteni kell regisztereket.
Vannak olyan programok is, amik az asm source kodot optimalizaljak.
En egyel talakoztam, de inkabb magam csinaltam az optimalizalast.

Pentium Pro-n allitolag mar nem kell ezekre ennyire odafigyelni.
Sajnos az AMD es egyebb procikrol sincs infom.

Hatranya:
- Megno a kod meret, de asszem ez mar nem igazan problema, mert a
memoria mar szinte ingyen van es a cache-ek is eleg nagyok.
- Az utasitasok elkenese miatt nehez kesobb megerteni, hogy mit
csinal a program. Tehat a szetkenesnek kell lennie programozas
utolso lepesnek.

Ha jol emlekszem par eve a Dr. Jobs Journal-ban olvastam rola.
http://www.ddj.com/
Pisti
+ - Re: meg mindig karakterfelismeres (mind) VÁLASZ  Feladó: (cikkei)

On 24 Feb 98 at 13:15, Nemes Marcus > wrote:

> Sziasztok!

Szia!

> Istvan irja:
>
> : Igen, tudom, hogy Te a legbaloldalibb 1-es bitet mondtad, de ha a
> : byte hatar az 111 sorozat kozepen van, akkor az xor-olt byte-ban a
> : legbaloldalibb 1-es 1->0 atmenet lesz.
[...]
> Az erdekes az elso peldaban az, hogy a 2. byte-ban valoban hulyeseget
> kovetunk el, de az 1. byte-ban mar megtalaltuk a nekunk tetszo atmenenet,
> igy nem kell tovabb keresni.

Jo, Te nyertel :)
Ha a feladat az, hogy az _elso_ feher-fekete atmenetet talaljuk meg,
akkor tenyleg jo.

> A MIN es a MAX kozotti nem sebessegbeli kulonbsegen a hetvegen kettetortem
> az agyam, reszemrol szabad a gazda, esetleg unsubs-olhatok a nem megfelelo
> szellemi szinvonalam miatt. :-)

Ha szabad a gazda, akkor megmondom: A kulonbseg az, hogy a sarkos
erintkezeseknel a MAX korbejarja a sarkosan erintkezo alakot is, mig
a MIN azt kihagyja, ket kulonallo alakzatnak tekinti. Szoval a MIN 4
szomszedos szomszedsaggal dolgozik, mig a MAX 8 szomszedossal, ott a
ferde szomszedok is szomszedok.

Ez elsore nagy kulonbsegnek tunik, valojaban csak az az erdekes, hogy
tudjunk rola, es konzekvensek legyunk. Tehat nehogy a betu bejaro
algoritmus MAX-szal dolgozzon, a lyuk bejaro meg MIN-nel, mert akkor
"egymasba gabalyodnak".

Hogy melyik a jobb? Kinek mi tetszik. Mi a MAX-ot hasznaljuk. A
gyakorlatban nagyon ritka egyebkent a sarkos erintkezes, mert a betuk
vizszintesen vannak nyomtatva. Azert elvekonyodo ferde vonalaknal jol
johet, hogy a MAX azokat a sarkos erintkezeseket is beleerti a
bejarando alakba, szoval valoszinu jol valasztottunk :)

No, akkor az igert folytatas:

Miutan korbejartuk az elso alakot, tovabb kell mennunk, es meg kell
talalni a masikat. Vagyis bejon most az, hogy hol van a rakovetkezo
feher -> fekete atmenet. Raadasul olyan, amit eddig meg nem jartunk
be. Tehat ha az alakzat teteje ilyesmi:

-> X x x x         Y x x x
   x x x x x     x x x x x
   x x x x x x x x x x x x
   x x x x x x x x x x x x

Akkor eloszor beleakadunk az X-be, korbejarjuk, ekozben jarunk az
Y-nal is, tehat amikor majd a masodik alakzatot keressuk, akkor mar
nem szeretnenk megtalalni az Y-t, mint uj feher->fekete atmenetet.

Annak adminisztralasara, hogy mik a mar bejart feher->fekete
atmenetek, a legjobb talan egy parhuzamos bitmap-et fenntartani (mi
ezt konturmap-nek nevezzuk), ahol is bejaraskor bejeloljuk azokat a
feher->fekete atmeneteket (vizszintes atmenetek), ahol mar jartunk.
Igy amikor a vektorunk az Y-tol balra felfele all, akkor beirunk egy
bitet az Y-al parhuzamosan a konturmap-be, es amikor a multkori
feladatban keresett and-shift-xor-stb. algoritmussal keressuk a
feher-fekete atmenetet, akkor abban figyelembe vesszuk ezt a
parhuzamos konturmap-et is.

No, ezek utan akkor a modositott FELADAT: hogyan lehet nehany
bitmuvelettel megtalalni a legelso olyan feher->fekete atmenetet,
ahol eddig meg nem jartunk?

Vegyetek azt is figyelembe, hogy ha a lapon van 1000 betu, akkor uj
feher->fekete atmenetet csak pontosan 1000-szer fogunk talalni
(eltekintettem az ekezetektol), mig mar bejart atmenetet esetleg sok
szazezerszer. Tehat az algoritmus azon reszenek kell gyorsnak lennie,
ami a mar bejart atmeneteket nem fogja megtalalni. Ha mar talaltunk
egy uj atmenetet, annak eldontese, hogy melyik biten kezdodik az,
lehet szinte akarmilyen lassu is, hisz egy lap felismeresekor csak
1000-szer fut le.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --
+ - Re: prog irasi tanacstalansag [UNIX] (mind) VÁLASZ  Feladó: (cikkei)

Kedves Lista && Marosi Istvan!

> > Nem tudom, hogy mi tortenik a nagy fork-olasok kozepette. Tudom, hogy a kod
csak
> > egyszer el, de ha nagyobb a kod, akkor nagyobb helyet fog foglalni a futas
> > kozben??? Hogyan lehetne elerni, hogy csak akkora kod legyen a memoriaban,
> > amekkora szuxeges. Ha a megvalositando feladatokat kulon fv-be teszem, az
> > eleg???
>
> Szerintem nem nagyon kell egy rendes unixon ilyenekkel torodni, ha
> kell a memoria, akkor a kernel ki-swap-ol mindenkit, raadasul a
> kodteruletet swap-olni sem kell, mert gondolom, nem firkalsz bele. :)
> Szoval meg swap teruletet sem nagyon foglal, amikor szukseg van ra,
> visszaolvassa a file-bol.

En ugy hallottam (pontyon infom nincs rola), hogy a Linux (nem tudom, hogy
a HP-UX is e' e) ugy csinalja, hogy csak par lapot olvas be a prog-bol.
Igy nem annyira lenyeges a meret, mert ugy sincs bent minden!

Nem erdemes esetleg shared izekkel megoldani a dolgot, vagy mar megint
huJeseget beszelek?

TIA && udv From:, a melle'kes szereplo

# Minden eronkkel tamogassuk azokat akik keresik az igazsagot...
# ... es menekuljunk azok elol, aki megtalaltak! /Vaclav Havel/
+ - Blinker (mind) VÁLASZ  Feladó: (cikkei)

Hasznalja valaki a Blinker 3 vagy a Blinker 4-es szerkeszto-
programot Clipper kornyezetben ugy, hogy a Clipper progit
extended-kent szerkessze? A leiras szerint csak 2 plusz sor
a .lnk allomanyba, de nekem meg sosem sikerult elinditani
az igy leforditott programot. Meg a legegyszerubb 1 soros
progi is kiakad GPF-el.
Van valakinek otlete ?

Koszi

Kesjar Attila
+ - Visual Foxpro 3.5 (mind) VÁLASZ  Feladó: (cikkei)

Hali mindenki !

     Keresem a fenti csodatermekben programozo elfajult egyedeket, hatha
     eszmet tudunk cserelni, esetleg megvaltani a vilagot.
     Tudom, hogy van mar ujabb verzio belole, de hat nekem csak ez van.
     Rajta hat !

     Udv : Peter
+ - Masolasvedelem demo (mind) VÁLASZ  Feladó: (cikkei)

Sziasztok!

Ha erdekel egy igazi, tisztan szoftveres masolasvedelem
-- pontosabban illegalis alkalmazashasznalat elleni vedelem --
demoja, a http://members.tripod.com/~devpoint/indigo.zip cimrol
letoltheted.

Bar egyelore meg fejlesztes alatt, es meg csak Win95 alatt fut,
a lenyeg kiveheto a demobol: a vedett program KIZAROLAG a
meghatarozott szamitogep(ek)en fog futni. Nincs hattertarolohoz
kotve (!), szabadon masolhato, igy keszitheto rola biztonsagi
masolat is. A vedelem hasznalatahoz nem kell atirni a vedendo
programot, utolag is elvegezheto a telepitese.

A mukodesehez nincs szukseg semmilyen kiegeszitore
-- pl. hardlock, vagy kulcslemez --, enelkul is biztonsagos,
gyakorlatilag nem torheto fel. Hogy miert? Mert a program
belepesi pontjat a futtato szamitogep "kulcsaval" titkositja,
igy a dekodolo resz a nem regisztralt szamitogepeken egyszeruen
nem tudja megallapitani, hogy hol kezdodik a program.

(Termeszetesen NEM erre epul a vedelem kozponti resze, ez csak
azt biztositja, hogy regisztralatlan gepen semmifelekeppen ne
lehessen hasznalni. Mivel azonban egy regisztralt programrol
nyomkovetessel eltavolithato lenne a vedelem, mas, joval
biztonsagosabb modszerek is megtalalhatoak benne, amelyek
garantaljak, hogy a toresi eljaras automatizalasa eseten (!)
is minimum 5-10 evbe kerul a vedelem feltorese.)

Udv, &:]

Suc
]
+ - ASPI felulet programozasa? (mind) VÁLASZ  Feladó: (cikkei)

Hello,

van vkinek vmilyen infoja az ASPI felulet programozasarol.
Konkretan egy Adaptec 2940 kartyan keresztul kellene adatokat kuldeni
es fogadni egy kulso SCSI egysegrol.
Vmi Pascal, vagy C megoldas erdekelne.

-------------------
GZsolt

mail:

2:
UIC: 5688612
+ - Delphi levelezolista (mind) VÁLASZ  Feladó: (cikkei)

Hello,

Beindult egy csak Delphi -vel foglalkozo levlista.

Jelentkezes:


Subject: subscribe

Udv,

awender
+ - Programmer's Oasis (mind) VÁLASZ  Feladó: (cikkei)

Hi!

Nincs meg a teljes CODER archivum (tenyleg, elkuldhetne valaki az 1..25
szamokat tomoritve...), de megkockaztatom, hogy nem mindenki ismeri meg a
Programozok Oazisat. En is az Uj Alaplapbol ertesultem arrol, hogy ilyen
is van. Tele van linkekkel, kis kereses utan barmit meg lehet benne talalni.
A C-t nagyon preferalja, de mas is van benne boven.
Tehat a cim:

http://www.utu.fi/~sisasa/oasis/alternate.html

Jo keresgetest!

  NGabor, az ujrakezdo programozo
+ - Karakterfelismeres (mind) VÁLASZ  Feladó: (cikkei)

>Szoval and-xor-stb.-vel kellene.
>> n := tabla(X) (szogletes zarojel!)
>
>Igen, lehet szo ilyesmirol is.
>
>Most nem erek ra, de mindjart irom a feladat folytatasat, es akkor
>erthetobb lesz, hogy miert kell megis nehany xor bele :)

A megoldas a kovetkezo:
v&((v-1)^0xff)
^ == XOR (ha valaki nem jaratos C-ben) :-)
v == v a vizsgalt byte.
A dolog azert mukodik, mert a kivonas a legelso 1-es bit felettieket
nem bantja, ezek a xor miatt kimaszkolodnak az AND-nel, az elso
1-es bit elotti reszek a kivonas kovetkezteben csupa 1-e valnak, es
oket mar a xor kimaszkolja, mig az elso bit a kivonas kovetkezteben
0-ra megy a Xor vissza viszi 1-be, es mivel az originalban is 1
ez a bit, az AND eredmenye az lesz, hogy ez es csak ez a bit lesz 1.
Megjegyzem ezzel a megoldassal mehetsz gyorsabban is mint 8 pixel,
csak a 0xff-et kell nagyobbra venni, na meg a regiszter meretet. :-)

Ezzel kapcsolatban jut eszembe, van egy hasonlo feladat, es a megoldas
is hasonlo:
hogyan lehet eldonteni gyorsan egy szamrol, hogy 2 hatvanya-e vagy sem.
Megoldast most nem irok, kivancsian varom hogy ismeritek-e.

Annak ellenere hogy kicsit kuriozumnak tunnek ezek a feladatok, meglepo
modon volt mar peldaul a fentire szuksegem.

Biczo Tibor
+ - Karakterfelismeres 2 (mind) VÁLASZ  Feladó: (cikkei)

[fekete feher el megtalalasa :]

Idokozben eszembe jutott egy picivel
elegansabb megoldas:
((v-1)^v)+1
Gyakorlatilag az elmelet ugyanaz mint az elobb.
Utasitasok szamanak szempontjabol is nagyjabol ugyanaz (mindket
megoldasnak 4 muveletre van szuksege), viszont nincs szukseg maszkra
s igy talan vagy egy register-el tobb van, vagy nincs szukseg egy
immediate param-ra a xor-nal.
Eredmeny ugyanaz, ha a vizsgalt adat 0 volt, akkor a kimenet 0,
kulonben az elso bitet adja vissza.
----
Kicsivel kesobb:
i80x86-on az elso megoldas a jobb, mivel van NEG utasitas,
ami pont megegyezik a (v-1)^0xff-el, raadasul mukodik byteon
es szon is.
Na szoval valahogy igy nezne ki: (AL-ben a vizsgalt byte)
MOV BL,AL
NEG BL
AND BL,AL

Utasitasszamban ez mar eleg keves :-), hogy orajelben mi a gyorsabb
azt mar nezzetek meg ti. Nekem csak 386-rol van most hirtelen
keznel info, es itt azt irjak hogy a fenti utasitasok mind 2 orajel
hosszuak, ugyhogy ez az egesz itt 6 orajel alatt lefut elmeletileg
386-on, pentiumon pedig ugy saccolom, hogy olyan 3 orajel lehet.
Ez mar eleg jo nem? :-)

Mas procin elkepzelheto, hogy a masodik megoldast jobban ki lehet
optimalizalni.

Biczo Tibor
+ - Karakterfelismeres 3 (mind) VÁLASZ  Feladó: (cikkei)

>Idokozben eszembe jutott egy picivel
>elegansabb megoldas:
>((v-1)^v)+1

Na igen ezt elirtam... A helyes a kovetkezo :
((v-1)^v)&v

A xor elintezi a felso biteket, es 1-be allitja a keresett bitet,
es az alatta levoket, az and pedig torli a keresett bit alatt levo
biteket.

Hmmm... Most vettem eszre, hogy balrol-jobbra tarto megoldast
kerestek, viszont ezek jobbrol-balra meno megoldasok.
Nem lenne egyszerubb, ha ugy tarolnad a pixeleket, hogy a
legbaloldalibb van a 0-as biten a kovetkezo az 1-esen etc...
Ha igy tarolod, akkor raadasul Intel(little-endian) kornyezetben tudsz wordot
is olvasni, es a bit sorrend helyes lesz ehhez a megoldashoz.
Ha viszont Motorola(big-endian) kornyezetben vagy, akkor persze erdemesebb,
ha ugy tarolod, hogy a legbaloldalibb a legnagyobb helyierteku biten van,
viszont itt erdemes akkor megfontolni, hogy a kep vegig scanneleset
ne balrol-jobbra, hanem jobbrol-balra vegezd...

Biczo Tibor

AGYKONTROLL ALLAT AUTO AZSIA BUDAPEST CODER DOSZ FELVIDEK FILM FILOZOFIA FORUM GURU HANG HIPHOP HIRDETES HIRMONDO HIXDVD HUDOM HUNGARY JATEK KEP KONYHA KONYV KORNYESZ KUKKER KULTURA LINUX MAGELLAN MAHAL MOBIL MOKA MOZAIK NARANCS NARANCS1 NY NYELV OTTHON OTTHONKA PARA RANDI REJTVENY SCM SPORT SZABAD SZALON TANC TIPP TUDOMANY UK UTAZAS UTLEVEL VITA WEBMESTER WINDOWS