> Felado :  [United States]

> iC>     bt  [si],cx
> iC>     adc dx,0
> iC>     dec cx
> iC>     jns cycle
> ize, ez szep es yo, felteve, ha a bitterkep hossza maximum 2 byte...
ize, ez szep es yo, felteve, ha a bitterkep hossza maximum 4095.875
byte. ;)))
meg visszafele 4096 byte. ha ecx-et hasznalsz, akkor pedig
268435455.875 byte,
plusz visszafele 268435456 byte. proba cseresznye!
hehe, en nyertem! ;))))

> gondojj bele monnyuk egy 64 byte hosszu bitterkepbe...;)))) akkor
> a cx-ben mar 64*8-1 lesz... az ugye 511... de akkor jon az alap kerdes,
> hogy egy wordben /bt [si],cx ugye wordos utaSITas/.... te6 egy wordben
> hogy lehet letesztelni az 511. bitet? ;))))))))))))))))))))))))))))))
ha reg-et hasznalsz, akkor term. csak abban lehet cimezni, viszont
memben annyi bitet, amennyi belefer a cimzo reg-be.

Bye,
	Panther / mnemonic

On 25 Apr 99 at 22:06,  wrote:

> no en magam reszerol valahogy ugy csinalnam, hogy...
>  - kiuritem a tablazatot...
>  - osszeszamolnam, hogy mejik bytebol mennyi van...
>  - majd vegigmennek a tablan, es szorozni ezerrel...

No, meg egy teljesen uj megkozelites!
Erdekes elgondolas, tetszik.

Bizonyos esetekben meg talan hasznos is lehet (nagyon nagy meretu 
memoriaterulet, keves fele bitmintazat a byte-okban [lasd kesobb])...

> ui: kar, hogy nem lehet shr-t hasznalni, mert azzal egy kicsit
>     gyorsra lehetne aszt a BitCountot irni...

Nem literalisan ertettem, hogy tilos shr-t hasznalni, hanem az 
algoritmusra gondoltam. Viszont ezzel a szorozgatos svedcsavarral 
nyugodtan johet a shiftelos BitCount is.

> GetResult_j1:
> call BitCount                ;na nezzunk hany 1es is van ebben a byteban?
> imul ecx,cs:[edi+eax*4]      ;* hogy hany ijen bytet talaltam....

Annyit azert erdemes lett volna beletenni, hogy ha [edi+4*eax] erteke 
0, akkor ne szamolja ki a BitCount-ot feleslegesen. Igy ha keves fele 
mintazat van a bitekben (kep eseteben elegge tipikus), akkor sok idot 
lehet sporolni.

> BitCount_j1:
> bsf dx,ax                    ;keressunk 1 bitet...
> jz byte BitCount_j2          ;aki keres, nem mindig talal-->vegre vege! ;)))
> inc cx                       ;ollejj, novejjuk a szamlalot...
> btr ax,dx                    ;torojjuk a talalt bitet...
> jmp byte BitCount_j1         ;es ujra, 6ha van meg kis lapulo bitecske...
> BitCount_j2:

Ez a bit scan-es rutin viszont naaaaaaagyon lassu. :(
Itt egy adat ra (normal Pentium orajelek, 256-szoros ciklusra):

 ShiftAdc Unfold8          5092  4887  4882  4883  4882
 BSF                      40876 40856 40856 40853 40853

(Az 5 szam 5 egymas utani meresben az orajelek szama, ebbol az elso 
nem tul erdekes, mert akkor meg a cache nem allt be rendesen.)

Szoval tobb, mint 8-szor lassabb a bsf-es bitcount, mint egy shr-en 
alapulo.

Tudom, 'nem lehetett hasznalni' ... :)

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

On 25 Apr 99 at 22:06,  wrote:

> iC>     bt  [si],cx
> ...
> ize, ez szep es yo, felteve, ha a bitterkep hossza maximum 2 byte...

Ezt rosszul tudod, szepen mukodik ez. Probald ki. A proci klasszul
kiszamolja, es hozzaadja si-hez, amit kell...

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

Szevasztok!

On 25 Apr 99 at 0:59,  wrote:

> 1. shift-es modszer referenciakent (felteteles ugrasokkal szerintem
> lassabb lenne) 4710 orajel

Megirigyeltem Toled az orajeleket, ugyhogy megmertem en is az elozo
napokban megjelent (meg nehany shift-es) bitszamolo algoritmusok asm
verzioit.

En egy regi fele Pentiumos gepen mertem, pucer dos alatt (apropo: nem 
tudjatok, hogyan lehet engedelyezni az rdtsc utasitast win alatt?)
Mindenesetre eloszor nagyon meglepett, hogy az asm rutinjaim joval 
tobb orajelet zabaltak, mint a Te C++ rutinjaid, aztan amikor az 
egyiket en is megmertem, rajottem, hogy a Pentium / PentiumII 
processzor kulonbsege az oka. (Pentium 6415 orajel / PentiumII 4710 
orajel.)

A tablazathoz elozetesen:
- A megnevezes elotti szam a rutin hossza byte-ban, beleertve a vegen 
a ret utasitast is.
- Az orajelekbe viszont nincs beleszamitva a ret (Ez az ures rutin 0 
orajelen latszik)
- 5 meres volt egymas utan minden rutinra, ezekbol az elso meg 
egyaltalan nem pontos, mert a cache olyankor meg nem toltodott fel.
(Gondolom ez az oka, de Balala biztos jobban tudna...)

A program forrasa megtalalhato a 
http://www.sch.bme.hu/~marosi/incoming konyvtarban, bitszam.asm 
neven. Leforditva is megvan ugyanott.

   1  Ures rutin                 102     0     0     0     0 
  29  ShiftAdc while            8964  8798  8798  8798  8798 
  28  ShiftAdc until            6570  6416  6412  6412  6412 
  57  ShiftAdc Unfold8          5092  4887  4882  4883  4882 
  82  ShiftAnd1 b               5672  5426  5422  5423  5423 
  77  ShiftAnd1 pipe            4843  4648  4649  4649  4648 
  91  ShiftAnd1 Cpp             6689  6425  6414  6415  6421 
  27  BSF                      40876 40856 40856 40853 40853 
  31  Rekurziv 2call            6715  6557  6557  6557  6557 
  36  Rekurziv 1call            2717  2578  2574  2573  2572 
  56  Rekurziv 1call Unfold4    1246  1014  1020  1012  1012 
  35  Dupla ciklus              1479  1345  1340  1339  1340 
  47  Dupla ciklus Unfold4       678   507   507   507   507 
  34  Szimpla ciklus             978   815   815   815   814 
  49  Szimpla ciklus Unfold4     411   353   353   353   353 

Megjegyzesek:
- ShiftAdc while / ShiftAdc until szinte azonos, megis nagy kozottuk az 
orajelek szamaban a kulonbseg. Vegulis ertheto, a while ciklusban ket 
ugras van, az until-ban csak 1.
- Ide a sorlimit miatt nem is tettem be, de a programban megvan tobb 
rutinnak a byte-os regisztert hasznalo valtozata is, es erdekes, hogy 
azok rendre lassabbak a szavas regisztert hasznaloakkal szemben. 
Illetve neha ez nem igaz (ShiftAdc until), attol fuggoen, hogy hova 
teszem ezt a rutint a tobbihez kepest. (Nem ertem, de biztos igaza 
van... :)

Az azert nem semmi, hogy a 'Szimpla ciklus Unfold4' Pentiumon szinte 
ugyanannyi orajel, mint a 'Dupla ciklus Unfold4' PentiumII-n. :)

Mindenesetre a tanulsag, ami a szamok nagysagrendi kulonbsegeibol 
latszik, hogy egy jol atgondolt algoritmus sokkal tobbet erhet, mint 
egy atlagos algoritmus finomhangolasa.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

Kedves Istvan!

> > > > > Az abc ugyanis nem pointer.
> > > > Szerintem meg igen.
> > > Pedig bizony nem... :))
> > Dedededede! Es a dupla stipi-stopit nem er megkontrazni! :-)
> 
> Jol van na, legyen igazad, az abc egy pointer. :)

Na azer'! Szerencsed, hogy oregapadnak szolitottal, mert en vagyok ittr a 
KISZ titkar! :-)

> > > Nincs def pointer sehol a memoriaban, ahova betoltodhetne barmi is!
> > Dehogynem. Nezd meg a kodot asm-ben.
> 
> ??? Neztem! Nincs.
> Milyen processzoron nezed Te? El tudom kepzelni, hogy valahol van.

Igazad van, kicsit tulspiraztam. Nem kell betoltodnie semminek, mert a 
fordito mar tudja, hogy hova kerul es a vegrahajthato adatraszeben mar 
definialva is vagyon.

> > > > "x.c", line 4: left operand must be modifiable lvalue: op "="
> > > 
> > > Ez a hibajelzes nem azt jelenti, hogy konstans!! Hanem azt, hogy nem
> > > lvalue.
> > 
> > Es egy valtozo mikor nem lvalue? Amikor konstans! Vagy neeeem?
> 
> Most mar annyira belezavartal, hogy fogalmam sincs, hogy mi az az 
> lvalue.

Aminek erteket lehet adni. Ha egy valtozo bal oldalt all es nem lehet neki 
erteket adni, akkor annak (szerintem) konstansnak kell lennie.

> Mindenesetre itt egy kodreszlet, kommentekben, hogy az ms C++
> fordito milyen hibajelzeseket ad ra:

Elkovettem meg egy hibat, en C oldalrol tekintem a dolgot. C++ az egy kicsit 
mas allatfaj...

> char tomb[10];
> const char *poi;
> 
> void akarmi()
> {
>    *poi = 'a'; // hiba: l-value specifies const object
>    poi++;      // ez rendben
>    tomb = poi; // hiba: no conversion from 'const char *' to 'char [10]' }

es ha type cast-olod??? Szerintem fog az menni. A C++ kicsit jobban nezi a 
dolgokat, mint a C...

> Most nem boot-olok linuxot, hogy a gcc milyen hibakodokat ad.

Nekem nem kell. Az NT magatol is kifagy...

> Olyat, hogy konstans pointer, nem birtam a C-bol kicsiholni. A 'char const
> *' ugyanaz, mint a 'const char *'.

En ezt ugyilag gondoltam, hogy a pointer erteket nem igazan szivesen irja 
felul a Co:. Szerintem lehet ezt forszolni! :-)

Udv From:, a Pi-vizelo"

Idot, penzt, faradsagot takarit meg, ha idot, penzt, faradsagot takarit meg...

Hi !

> Csak egy rovid kerdes: Hasznal valaki Win NT alatt 32 bites Resource
> WorkShop-ot? Mar minden file-t beszereztem hozza megse megy. Egy kis
> homokorazas aztan semmi? Masnal '95 alatt persze megy.
> Megoldas? (Nem cserelem le az NT-t!!!  :-)))  )

Nem tudom mennyire tokeletes megoldas, mert RS workshopot utoljara w3.1
alatt hasznaltam, de a Delphi 3-ban a pelda progik kozott van egy
Resource editor peldaprogram. 

Ez biztos fut NT-n is, mert ezt mar probaltam.
Mivel pedig mint minta prg megvan forrasban, ez ket dolgot eredmenyez :

1. Ha valamit nem , vagy nem jol csinal, lehet tuningolni

2. Ez egyben valasz azoknak, akik kerdik hogy hogyan lehet programbol
resourcot kezelni. Ott a forras ki kell nezni belole.  (ha nem igy
volna, ne kovezzetek, nem neztem meg ilyen szinten)


Es a vegere megegyszer megkerdeznem, hogy tenyleg nincs senki akinek
meglenne a Delphi 3.01 CD ?

Udv:
-- 
Csiszar L.
http://www.stadium.hu/szt/

Sziasztok!

Csiszar irta:
Delphi 3-ban a pelda progik kozott van egy Resource editor peldaprogram. 

Milyen igazad van! Ez eszembe sem jutott.

Udv

Szucs Zoltan

Hello Mindenkinek !

  Egy problemaval fordulok hozzatok, amire hiaba kerestem a valaszt
eddig, remelem ti tudtok segiteni.
  Asm-ben irt memoriarezidens programot szeretnek a program futasa utan
zaroakkordkent kitakaritani a memoriabol. Ha tudnatok irni par sort, hogy 
lehetne mindezt veghez vinni, nagyon halas lennek.
  
  Elore is koszi

                                    Udv.:          OCSI

Sziasztok,

   Keresek JPEG leirast, vagy forraskodot. A cel BMP-re valo atalakitas
lenne. 
   
Elore is koszonom a segitseget

Szasz Oliver

Sziasztok!

Elküldöm megint, mert semmi reagálás nem volt.
Lehet, hogy a kérdésem rosz?
Pedig az Access is ugyanezt teszi ugy tunik, tehat nem hajlando
figyelembe venni a tizedesjegyek szamat, ha dbf-be exportalok.
A delfiben meg be sem tudom allitani

_Segitseg!_
_Ez nekem nagyon surgos!_

> Sziasztok!
>
> Van meg egy kerdesem a delphi adatbaziskezelesevel kapcsolatban.
> Ha dbase progival letrehozok egy adatbazist, abban egy numerikus mezo
> formatumat meg tudom adni. Nekem pl most a 10.2 formatumra van szuksegem.
> A feladatom azonban most az, hogy delphivel hozzak letre dbf adatbazist,
> amin
> mar nagyreszt atragtam magam. Egy bajom van, a delphit nem tudom ravenni
>  a 10.2 formatumra, folyton 20.4-et allit, es az nekem nem jo!
> Kerlek segitsetek!
> kuldjetek maganba is mindenkepp, mert azt hamarabb megkapom.
>
> koszi
> Dezso
>

Sziasztok!

Mintha az lenne a baj, hogy kulonfele keppen definialjatok a pointert.
Szerintem a pointer az egy valtozo, aminek az erteke valahol a memoriaban
tarolva van. A tomb az nem ilyen. Az csak egy puszta szam, ami ele nem kell
typecast, ha egy pointernek ertekkent akarod megadni.
Tehat a
char tomb[200],*ptr;
tomb=ptr;
nem azert nem lehetseges, mert a tomb az char const * (es plane nem const
char *), esetleg const char const *, hanem azert mert a tomb az olyan mintha
define-olva lenne az erteke.

Folyton hivatkoztatok a disassembly-re, ime (VisualC 6.0):

void f(char *);

5:    int main()
6:    {
00401040   push        ebp
00401041   mov         ebp,esp
00401043   sub         esp,10Ch
00401049   push        ebx
0040104A   push        esi
0040104B   push        edi
7:        char tomb[200];
8:        char *ptr;
9:        f(tomb);
0040104C   lea         eax,[ebp-0C8h]  ; <--- ez egy konkret szam.
ebp-0xC8-nal van a tomb.
00401052   push        eax
00401053   call        @ILT+0(f) (00401005)
00401058   add         esp,4
10:       f(ptr);
0040105B   mov         ecx,dword ptr [ebp-0CCh] ; <--- ebp-0xCC -nel van a
pointer, onnan olvassuk ki az erteket.
00401061   push        ecx
00401062   call        @ILT+0(f) (00401005)
00401067   add         esp,4
11:       ptr=tomb;
0040106A   lea         edx,[ebp-0C8h] ; Hasonloan
00401070   mov         dword ptr [ebp-0CCh],edx
12:       return 0;
00401076   xor         eax,eax
13:   }
00401078   pop         edi
00401079   pop         esi
0040107A   pop         ebx
0040107B   mov         esp,ebp
0040107D   pop         ebp
0040107E   ret

[...]
>> > leforditott ertek lesz a def-ben es utanna nem irhatod at. Ugyanis
>> > forditaskor 29 byte le lesz foglalval valahol es az erre mutato POINTER
>> > betoltodik a def pointer-be.
>>
>> Nincs def pointer sehol a memoriaban, ahova betoltodhetne barmi is!
>
>Dehogynem. Nezd meg a kodot asm-ben.
Lasd fent. Most mar elhiszed?

[...]
>> Ez a hibajelzes nem azt jelenti, hogy konstans!! Hanem azt, hogy nem
>> lvalue.
>
>Es egy valtozo mikor nem lvalue? Amikor konstans! Vagy neeeem?
A problema az, hogy nem valtozo. Hanem konstans. Mint pl:
#define videomem ((char *)0xa0000)

Udv,
Marton

Sziasztok,

koszonom szepen mindenkinek a targybeli temaban a valaszokat, a nyero
megoldas eddig 0x52 -es dos megszakitas hasznalata.
Ez gyonyoruszepen mukodik real modban. Nekem a progim sajna vedettmodu
es clipperes exospace-szel forditva. Namost innentol kezdve nem mukodik
a realmodu cimzes.

Az alapalgoritmus a kovetkezo:

struct SFTstru
{
        struct SFTstru far *Next;
        unsigned num;
};

unsigned MaxFiles(void)
{
        struct SFTstru far *SFT;
        union REGS regs;
        struct SREGS sregs;
        unsigned int sum=0;

        regs.h.ah=0x52;
        intdosx(®s,®s,&sregs);
        SFT=MK_FP(sregs.es,regs.x.bx+4);
        SFT=SFT->Next;

        while (FP_OFF(SFT)==0xFFFF)
        {
                sum += SFT->num;
                SFT=SFT->Next;
        }

        return sum;
}

Rendelkezesre all egy 
void* ExoProtectedPtr(void* rmptr, unsigned int sizebytes)
tipusu fv, ami real ptr-bol protectedet csinal. Namost ezt semmilyen modon
nem tudom belevarazsolni a progiba, sehogy sem mukodik.
(Mas helyen egyebkent csudaszepen dolgozik ez a fv)
Peldaul a ciklusfeltetel talan mashogy alakul protected modban :)
Maskepp alakul a Next adata is talan?

Ha valakinek van otlete, ... :)

Koszonettel:
Tibi.