1. |
16/32 bit (mind) |
48 sor |
(cikkei) |
2. |
16/32, RTKernel (mind) |
23 sor |
(cikkei) |
3. |
Fizikai memoria cim vedett modban (mind) |
42 sor |
(cikkei) |
4. |
2^4 vs. 2^5 (mind) |
96 sor |
(cikkei) |
5. |
Linux vasarlas, memoria teszt... (mind) |
37 sor |
(cikkei) |
6. |
Re: ELLA, csomagradio? (mind) |
22 sor |
(cikkei) |
7. |
Re: Linux meghajtok (mind) |
11 sor |
(cikkei) |
8. |
Apple ][ help! (mind) |
17 sor |
(cikkei) |
9. |
Re: vegyel linuxot?!? (mind) |
29 sor |
(cikkei) |
10. |
Segiiitseeeeg! (mind) |
6 sor |
(cikkei) |
11. |
A felejthetetlen SUN, (sun10) (mind) |
31 sor |
(cikkei) |
12. |
16/32 (mind) |
69 sor |
(cikkei) |
13. |
FTP server tukrozese (mind) |
23 sor |
(cikkei) |
14. |
Windows NT + Novell 3.12 (mind) |
6 sor |
(cikkei) |
15. |
proba (mind) |
13 sor |
(cikkei) |
16. |
Hatvannyolcezer bit (mind) |
31 sor |
(cikkei) |
17. |
AudioFile (mind) |
24 sor |
(cikkei) |
18. |
Hatvannyolcezer-nyolc bit... (mind) |
33 sor |
(cikkei) |
19. |
Melyen tisztelt GURU! (mind) |
22 sor |
(cikkei) |
20. |
PREHISTORIK 2 (mind) |
10 sor |
(cikkei) |
21. |
PREHISTORIK 2 (mind) |
10 sor |
(cikkei) |
|
+ - | 16/32 bit (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Kedves Balogh Mihaly !
> Ha sok a cimvonal, akkor a fizikai cim kiszamitasa eleg
> sok idot vehet igenybe, az atvitelek miatt.
Ez kicsit meredeknek tunik. Alapvetoen igazad lehet, de a gyakorlatban
szerintem nem sokat szamithat. Meg kellene kerdezni egy CPU tervezot, milyen
gyorsitoaramkoroket hasznalnak a sokbites osszeadasok gyorsitasara...
> Ha valahol leallitjuk az
> atviteleket, akkor valamivel gyorsabb lesz a rendszer: ezen alapulnak a
> szegmenscimzesek. Persze 486-nal mar erzekelhetetlenek a kulonbsegek.
> Viszont a 8086-nal szerintem epp ezert vezettek be a dolgot.
Szerintem meg azert, mert a 8086-os processzor teljes belso architekturaja,
minden regisztere (a programszamlaloja is) 16 bites, ami alapesetben csak
64K cimtartomany megcimzeset tenne lehetove, ugyanugy, mint a Z80-nal. Mivel
tul akartak lepni a 64K-s cimtartomanyt, ezert bevezettek a
szegmensregisztereket, amelyek szinten csak 16 bitesek, de a cimaritmetika 4
bittel eltolva hasznalja oket. Ezzel a trukkel a cimtartomany 16-szorosara
nott (1 MB).
> Persze, mar a Z80 is ki tudta rakni akar az egesz kepernyot egy utasitas
alatt...
Az LDIR utasitasra gondolsz ? Az csak a programozo szamara egy utasitas, a
CPU a gyakorlatban minden byte atvitele utan ujra es ujra eloveszi es
vegrehajtja ugyanazt az utasitast (csak annyi a trukk, hogy nem noveli
kozben a PC-t). Idoben tehat (tudomasom szerint) nem kulonbozik attol,
mintha leirnal egymas utan sokezer LDI-t.
Kedves Krisztian !
> Azok a gepek, amik 32 bites cimeken keresztul kepesek a memoriat cimezni,
> azok 32 bitesek, amik nem, azok nem 32 bitesek.
Eszerint a 8086-os egy 20 bites processzor. Nem inkabb a belso
adatregiszterek szelesseget kellene figyelembe venni ?
> Ebben az esetben, az hogy hany darab lab van a processzorra illesztve, az
> teljesen mindegy, mivel adatokat lehet kevesebb labra is multiplexelni es
> ezaltal a processzor arat lecsokkenteni.
Egyetertunk, kiegeszitesul annyit, hogy nem annyira a processzor, mint
inkabb a kulso aramkorok aranak csokkenese a lenyeges.
Udvozlettel:
Hunyady Istvan
|
+ - | 16/32, RTKernel (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Felado :
> Azok a gepek, amik 32 bites cimeken keresztul kepesek a memoriat cimezni,
> azok 32 bitesek, amik nem, azok nem 32 bitesek.
> Az hogy egy adott utasitas hany bit-nek a tartalmaval foglalkozik, annak
> ahhoz nincs sok koze, hogy a processzor hany bites (persze a programozhatosag
Hat en moszkvaban ugy tanultam, hogy eppenseggel a cimbusz
szelessegenek nincs koze ahhoz, hogy hany bites a CPU, annak viszont
annal inkabb, hogy az aritmetikai egyseg hany bittel tud egyszerre
elvegezni egy osszeadast (akkoriban meg az osztas-szorzas nem volt
divatban). Szoval szerintem se a labak szama, se a regiszterek merete,
hanem az ALU kepessegei...
Komolyra forditva a szot: van valaki koztetek aki ismeri az OnTime
(vagy mi a szosz) ceget? Van nekik valami RTKernel nevu real-time
kerneluk PC-re, C es Pascal forrassal egyutt is. A hirdetesben igen szep
dolgokat irnak rola es nem is nagyon draga. Ha esetleg van valakinek
rola tapasztalata, kerem irjon! Real-time operacios rendszrek
oktatasahoz szeretnenk hasznalni.
Dani
|
+ - | Fizikai memoria cim vedett modban (mind) |
VÁLASZ |
Feladó: (cikkei)
|
16 es 32 bites GURUk!
Sajnos arra vagyok karhoztatva, hogy win32s/winNT ala fejlesszek.
Jelenlegi felallas az, hogy win3.11+win32s -en fut az alkalmazas, ez hivogat
egy
32-es DLL-t, az egy 16-os DLL-t (UT).
Ezen utobbi DLL-be "bele van linkelve" a DSP kartya (TMS320C30) gyari
lib-je (DOS statikus, .LIB).
Ezzen nincs is gond, elso kozelitesben. Az alkalmazoi program indul, behozza
a DLL-eket, a DLL inicializalja a kartyat, memoriablak letrejon, minden mukodik
.
Az alkalmazoi program kilep, DLL-ek tavoznak (tavoznak?), de elotte a
kartyaval becsukatom a memoria ablakot.
A baj akkor kezdodik, ha valaki ujbol inditja az alkalmazast, ekkor ez nem
mukodik.
A win32-UT-16 miatt a debug-olas eleg melos, ezert ugy dontottem, hogy
keszitek egy tiszta 32 bites driver. A kartya portjait szepen csiklandozom,
de hogy tudom elerni a memoria ablakot?
Hosszu bevezeto utan a fo kerdesek:
1, ugy tudom, winNT-n egy alkalmazoi program nem banthat fizikai memoriat,
de a device driverem hogy tud egy meghatarozott fizikai memoriacimet
lefoglalni,
irni/olvasni, felszabaditani?
2, Hogy lehet ugyanezt megcsinalni win3.11/win32s alatt? van kernel szintje
a win32s-nek is, vagy kizarolag win driverrel?
Egy hete az SDK/DDK-t bongeszem, de nem talatam semmi kezzel foghatot, a
megrendelo meg nem hajlando Linux-ot hasznalni.
Egyebkent, a winDDK peldaprogramjai mind ASM-ek, csak nem abban irtak a win-t
is :)?
Kosz a segitseget,
Lajbi
> ------------------------------------------------------------------------
Zoltan LAJBER _/ _/ _/ _/_/_/
Ecole Superieure de l'Energie et des Materiaux _/ _/_/ _/_/ _/
Laboratory de Mecanique et Energetique _/ _/ _/ _/ _/_/
Rue Leonard de Vinci _/ _/ _/ _/
45072 ORLEANS Cedex 2 _/_/_/ _/ _/ _/_/_/
E-mail:
> ------------------------------------------------------------------------
|
+ - | 2^4 vs. 2^5 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Kolonits Zoltan irja:
>>A regi szep (8-16 bites) idokben nem volt virtualis memoria. Ezert
>>minden nagyobb program valamilyen overlay technikat hasznalt. Ezekben
>>kozos volt az, hogy a lemezrol akkor cibaltak be ujabb kodreszleteket
>>amikor azokat a program felhivta. Ha a programozo csak tiz percet raszant
>>az overlay csoportok kialakitasara, akkor ilyen modon viszonylag keves
>>folosleges szemetet toltott be az overlay. A virtualis memoriaban (32 bit)
>>viszont nincs ilyen struktura, a program laponkent (altalaban 4K) jon be.
>>Mivel nincs semmi ami az osszetartozo programreszeket egymas melle tenne
>>a programban, altalaban rengeteg felesleges dolog van a behozott lapon.
Eloszor, az overlay-technika (mar amit en ismerek), nem fuggvenyenkent,
hanem modulonkent dolgozik, igy kell megadni a fat a linkernek. Azaz ott
is sok felesleges resz jon be.
Masodszor, az a feltetelezes, hogy virtualis memoria eseten laponkent
jon be a program, azert santit egy kicsit. A valosagban ugyanis egyszerre
jon be a program, es kifele swappelodik (nem befele). A swappeles
kerdese amugy is tulfajult a GURUn, a Windows meg Warp es tarsaik miatt
van ennyire eloterbe hozva. Egy 'normal' DOS alatti 32-bites programnal
nemigen van swappeles, ugy irja meg az ember (persze sokfele van beloluk),
hogy beferjen abba a 8 vagy 16 megaba.
Harmadszor, ha mar swappelesrol beszelunk, vegyuk eszre, hogy nem a kod,
hanem az adatok swappelese a kritikus. A kod merete ugyanis azert egy
megaba mindig elfer (a nagyon extrem kivetelektol eltekintve), 4 mega
alatt ugysem futtat senki 32-bites programokat, tehat a lefoglalt memoria
tulnyommo resze az adatok tarolasara megy el. Annak meg semmi koze
az overlay-hez.
Negyedszer, az az allitas, hogy nincs semmi, ami egymas melle tenne
az osszetartozo programreszeket, erosen ellentmond a gyakorlatnak,
a lokalitas elvenek, miszerint a programok szeretnek egy helyben (vagy
egy-ket helyben) topogni, a programozok meg pusztan logikai es olvashatosagi
okokbol szeretnek egymas melle olyan fuggvenyeket tenni, amiknek azert
valami kozuk van egymashoz, ugyhogy az a behozott 4K-s lap azert nem
lesz teljesen felesleges.
>> Illetve meg van: manapsag minden valamirevalo programozo az objektum-
>>orientalt divatot koveti (mas kerdes, hogy tudja -e mit csinal :-)
>>A modszernek alapveto kovetkezmenye, hogy az objektum osszes eljarasa,
>>a gyakran es sohasem hasznaltak, egymas melle kerul a programban. Vagyis
Ketfele ember van, az egyik tudja, hogy mi az az objektum-orientalt
programozas, es hasznalja is azt, a masik tipus pedig ezen elobbi
nepcsoportot cikizi es szidalmazza, mert jol nez ki es cool (no meg a cikizeshe
z
nem kell hozza erteni, eleg olvasni rola a c't magazinban).
A modularis programozasban is egymas mellett vannak a logikailag osszetartozo
(mert a programozo sajnos nem optimalizal fejben, hanem csak asszocial es
rendszerez) reszek, nem kell ehhez rogton az objektumokhoz kapkodni.
>> Ja, es meg valami. Minden (kereskedelmi) program pontosan olyan lassu,
>>hogy meg eppen kibirhato legyen. A modern programok persze a modern
Van sajnos egy olyan 'ellentet', ami a sebessegoptimalizalt es az attekintheto,
karbantarthato programok kozott feszul. A kereskedelmi programoknal fontos
szempont az, hogy kovetni lehessen, tovabbfejlesztheto legyen, stb.
Charles Simonyi (picipuha) mondta azt, hogy rossz az a felfogas, miszerint
a Windows NT-hez tul nagy processzor es tul sok memoria kell, hogy normalisan
fusson. Az igazsag - szerinte - az, hogy a Windows NT-t eppen olyan gepekre
terveztek, amiben sok memoria es gyors proci van - a hardver fejlodik, hat
megfelelo szoftvert kell ra irni, nem pedig a lassu szoftver miatt kell gyors
hardvert csinalni.
irja:
>>Azok a gepek, amik 32 bites cimeken keresztul kepesek a memoriat cimezni,
>>azok 32 bitesek, amik nem, azok nem 32 bitesek.
Hurra masodszor!!!
Zalka ERN0 irja:
>>Csak egy rovid kerdes Barczi Imrenek, meg aki valami okosat tud
>>hozzaszolni:
>>
>>A M68008 hany bites?
32 bites. Mar ket GURU is egyetertett ebben, Erno!!!
>>Lattam valamelyik PowerPC processzor belso szervezeset, hat ott aztan
>>32-tol 128-ig mindenfajta szoszelesseg elofordult a kulonbozo egysegek
>>kozott, na, az hany bites? ;-)
Vegyunk egy atlagerteket es legyen 80 bites :-)
Udv,
Imre
|
+ - | Linux vasarlas, memoria teszt... (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Heknyekukk! :)
Nem vagyok benne biztos, de azt gondolom, hogy aki a Linux CD -t
megvette az nem vette meg a Linux -ot. Ezt abbol gondolom, mert ugy
tudom, hogy a Linux -ert mint programert _TILOS_ penct kerni, a
mediaert vagy a masolasert lehet. Ha tehat walaki megveszi a Linux
CD(ket), amik annyira olcsoak, hogy csak tenyleg a korong ara lehet
bennuk, nem vasarol programot. Ilyen okbol tenyleg nem lehet massal
operencias rendszerrel osszehasonlitani, mert ingyen van!
Azt viszont nem egeszen tudom, hogy a Linux milyen esetekben
(uzleti eletben is?) hasznalhato ingyen. Talan megerne Linux
telepitessel foglalkozni, hiszen a program ingyen van? :)
-------------------
Memoria teszt:
Nem csak, hogy vannak memoria tesztelo programok, hanem a
hardware vizsgalatanak egyik marginalis reszet kepezik. Ez azert van
igy, mert a memoria _TENYLEG_ meghibasodhat, raadasul annyira fontos
eleme a gepnek, hogy anelkul nem igazan megy. (Lasd paritasbit
ellenorzes). Soxor eleg ha csak elbarmolja az ember a PC setup -jat,
mar jon is a hiba.
Ami a memoriaellenorzest erdekesse teszi az az, hogy elmeletileg
barmilyen hiba lehet, ami csak egy adott bitkombinacianal jon elo,
figyelembe veve a teljes memorichip osszes bitjet. Ha viszont olyan
programot akarunk irni, amely a memoriat minden kombinacioban
kiprobalja, akkor nagyon nagy futasi idok jonnek ki (monggyuk xmillio
ev)
Szerencsere altalaban nincs szukseg ilyen furmanyos ellenorzesre,
mert a felmerulo hibak elojonnek egyszerubb kombinaciok eseteben is.
Erdemes azonban arra gondolnunk itt, hogy mi a teendo egy uj chip
kifejlesztese utani teszteknel?
Az igazan eros memoriatesztek (vagyis azok, amiket akkor hasznal
az ember, amikor mar tudja, hogy valami nem stimm), azt is jo ha
megmondjak, hogy hol van az a chip, amelyik hibasan mukodik. Lattam
olyat, ami grafikusan kirajzolta a chip -ek (akkor me'g DIL)
elhelyezkedeset az alaplapon, jelolve a cserelendot.
Leslie J. Pere Who is that General Failure and why is
(36-72) 411-433/3262 he reading my drive?
|
+ - | Re: ELLA, csomagradio? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
In article >, (Szalay Tama
s) writes:
>>
>> In article >, writes:
>> >Hogyan lehet ELLA-s postaladat Internetrol olvasni?
>>
>> Ha meg varsz egy-ket hetet, akkor POP3-mal es IMAP-pal.
>>
>
>Most portoljatok a POP3-at meg az IMAP-ot VM-re, vagy netan VMS alatt
>akartok bele eletet lehelni, hogy meg 1-2 hetet kell varni? U*x alatt a
>ketto egyutt akar fel oraig is tarthat. Meg elsore is. Kiveve persze, ha
>valami sosem latott mesebe illo ezoterikus u*x ala akarjatok felhuzni.
>Akkor lehet, hogy egy nap is kellhet hozza.
Nem talalt, sajnos csak ket kazettaval vigasztalhatom meg.
Az Ella atkerul a helka.iif.hu nevre hallgato immaronsolariskettopontnegy
op.rendszeru masinkara. Ahol a pop es az imap mar regesreg tart karokkal
varja. Egyebent megtisztel a tobbes szam elso szemely, de en nem veszek
reszt ebben a projektben, csak figyelem az esemenyeket.
Gabor
|
+ - | Re: Linux meghajtok (mind) |
VÁLASZ |
Feladó: (cikkei)
|
In article >, writes:
>Esetleg ismeri valaki Chase Research, Inc. (Naswille, TE) E-mail cimet?
Hivd fel a Kerszov Kft-t (regi munkahelyemet), ott ismerik a Chase
egyik hazai ugynoket, Geza Tothot. Szerezd meg az o szamat, es erdeklodj
tole. Mit lehet tudni. Egyebkent erdemes amitastechnikai magazinok
hirdeteseit bongeszni. Ha van e-postajuk, akkor ott megtalalod.
(Pl. Open Computing, azelott UnixWorld)
Maganvelemenyem: nem fogjak kiadni az informaciot a kartya programozasarol.
Gabor
|
+ - | Apple ][ help! (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok GURUzok!
A kovetkezo keressel fordulok a nagykozonseghez: jelentkezzen
minden olyan elvetemult orult, aki meg foglalkozik Apple ][ tipusu
hiperszupermegagiga szamitogeppel (vagy legalabbis tud olyanrol aki
meg most is hasznal ilyet ...). Elsosorban DOS kellene (nem MeSe...),
lehetoleg Apple es kb. 3.3-as (ugyanis ][e a dragam), de ha valaki
tud barmilyen hardware-t vagy software-t vagy akarmilyen infot a
kutyurol, az irjon nekem. Elore is koszi a faradtsagot!
Sziasztok!
-RatMan- from RatCave
Ui.: Ja, az MC68000-es akkor is 32 bites proci! A legjobb 32-bites
op'rendszere pedig az Great Amiga God-nak vagyon!(Esetleg buta
dobozon (PC) a Linux).
|
+ - | Re: vegyel linuxot?!? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> =======================================================
> Felado : Kiss Gabor
> E-mail :
> Temakor: Re: vegyel linuxot?!? ( 9 sor )
> Idopont: Tue Jun 20 07:53:23 EDT 1995 GURU #148
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> In article >,
> (Madarasz Gergely) writes:
>> Ki az a <oncenzura>, aki VESZ linuxot?!? ;-)
>
> En. Megeri nekem, hogy megvan a CD a polcomon, ahelyett hogy
> tobb tucat floppy-t masolgatnek es cipelnek haza.
> Meg ismerek masokat is. Akiknek az ido penz.
> Gabor az onceruza
Bocsi, azt hiszem kicsit elhamarkodottan irtam... Mellesleg en nem
masolgatok tobb tucat floppyt, ha linuxot akarok installni, ilyenkor kettot
hasznalok: root, es boot... nfs-rol igazan kenyelmes az installalas,
kulonosen mivel igy mindig a legujabb slackware-t tehetem fol...
A CD-vel az a bajom, hogy (szerintem) nem eleg friss, draga (nem
nagyon keresgeltem eddig, de egyszer lattam egy boltban linux CD-t 6000
Ft-ert! szerintem pofatlansag ennyit kerni), valamint nincs CD meghajtom
(Ezert is all az ajandek OS/2 WARP meg mindig a polcomon :-)), ezert meg
dragabb lenne (+20k vagy mennyi?). Udv.
Gergo
UI. meg egyszer bocsi, ha valakit megsertettem volna
|
+ - | Segiiitseeeeg! (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Date sent: 22-JUN-1995 15:31:01
Ha valaki el tudna magyarazni, hogy lehet ugy ftpzni, hogy ne kelljen megvarni,
orokre halas lennek. (vmi .netrc-vel kell+nohup)
Koszi
-= Ha Kap Eszi =-
|
+ - | A felejthetetlen SUN, (sun10) (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok !
Egyszer mar fordultam a kozonseghez a Sun-os problemaimmal, most ujabb
akadt. Miert olyan okos az oprendszer (Solaris 2.3), hogy ha a
'hostname ...' paranccsal megvaltoztatjuk a nevet, azt jol el is vegzi,
azaz elfelejti a regi nevet. Ugyanis a gep (SparcStation10) meg a
rendszerbe allitoktol a "sun10" fantaziadus nevet kapta. Ez jo is volt
egy darabig, amig valaki kitalalta, hogy legyen inkabb csak "sun".
A 'hostname sun' parancsot elfogadta a gep. Minden ugy tunt, hogy szuper
ugyanis senki sem hasznalta a gepet. A'm egy alkalommal egy ujrainditas
soran nem ismerte meg magat a gep. Szoval manualisan kellett meg atirni
a nalunk '/etc/hostname.le0' nevu filet, hogy ujra elinduljon.
Ekkor ugy tunt, hogy vegre normalis a gep es mar kezdtem azt hinni, hogy
nem is olyan rossz az a masina. Am jott az ujabb hiba.
Batorkodtam egy C programot leforditani, am az op. rendszer a kovetkezo
baratsagos uzenetet kuldte :
License Error : Cannot find the license server (sun10)
in the network database for product(SPARCompiler C)
Szoval meg mindig nem felejt...
Egyelore meg ugy allok, hogy nem tudok forditani, de elobb-utobb remelem
sikerul manualisan atallitani a megfelelo config filet (sun10->sun).
!!!
Hee, ha egy sun "boldog" tulajdonosa vagy, es esetleg van tipped,
akkor kerlek segits, de legalabb is vedd meg a munder becsuletet.
Koszi.
Miki
|
+ - | 16/32 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Udv!
Azert ezen a 16/32 dolgon nem kellene olre mennunk, de ha mar ugyis
itt tartunk...
>Azok a gepek, amik 32 bites cimeken keresztul kepesek a memoriat cimezni,
>azok 32 bitesek, amik nem, azok nem 32 bitesek.
Szerintem nem a cimbusz szelessege a meghatarozo. a 286 a maga 16 mega
cimteruletevel 24 bites? (mar megint kenytelen vagyok emlekezetbol
adatot irni)
>Ebben az esetben, az hogy hany darab lab van a processzorra illesztve, az
>teljesen mindegy, mivel adatokat lehet kevesebb labra is multiplexelni es
A sebesseg es a felepites szempontjabol nem mindegy. A program viszont
tenyleg semmit se vesz eszre.
>Szereny velemenyem szerint hiaba ul egy csonakban 8 helyett 32 izomos
>fiu, ha csak 8 lapat van...
A hasonlat santit. Mi van a multiplexelt kivezetesekkel? Plane, ha
a cim es adatvonalak vannak osszemixelve?
Barczi Imrenek:
Ha tenyleg a sebesseget tekintenek egyetlen jellemzonek, akkor de szep
volna minden...
A hatekonyabb program szerintem azt jelenti, hogy kevesebb utasitas
vegrehajtasaval hozza ki ugyanazt az eredmenyt. Nem a programban szereplo
utasitasok szamara gondolok, hanem ami tenylegesen vegrehajtasra kerul.
Ebben a kategoriaban szerintem meg mindig a C64-es programok vezetnek.
Ezt a fogalmat ujabb gepeken nehezebb megfeleloen ertelmezni: hasonlo a
helyzet, mint az utasitasciklusnal. Erre lehet pelda az altalad felhozott
utasitaspar is. (nem neztem utana)
Altalanossagban azonban elmondhato, hogy ugyanazon a gepen egy hatekonyabb
program gyorsabb is.
Az utasitasciklust csak a sebesseget okozo tenyezok szetvalasztasa kedveert
huztam elo. A ket tenyezo:
1: Utasitasciklusok hossza (orajelben vagy mikrosec-ben)
2: Utasitasciklusok mennyisege.
Amit a memoriaciklusok hosszarol irtakra valaszoltal, abban lehet, hogy
igazad van. Mindenesetre biztos pelda lehet a 6502 nullaslapos cimzese.
Ott meg szamitott a dolog.
Az 'erzekelhetetlen' szot azert hasznaltam, mivel meg nem lattam a 486-rol
idodiagrammot. Lehetsegesnek tartom, hogy ott is van kulonbseg egy egyszeru
es egy bonyolult cimzesmodu utasitas vegrehajtasa kozott.
(Pontosabban: a cimszamitasban biztosan van kulonbseg. Azt viszont nem
tudom, hogy ez a kulonbseg meg tudja e hosszabbitani az utasitasciklust.)
>>>Egyebkent meg az igaz, hogy ki tud rakni akar negy pontot is, 1 orajel alatt
,
>>>de hany programozo csinalja meg azt?
>
>Majd minden programozo hasznal mondjuk rep movs-t, ezzel 3 orajel 4 pont.
Erdekes. Szerfolott sok programot lattam mar, ahol a pontkirakasra kulon
rutint irtak. Melyik modszer az altalanosabb?
>>>Ahogy bovulnek az eroforrasok, ugy romlik a programok szinvonala|
>
>Ez egy axioma, vagy honnan kovetkezik?
Ez tapasztalat.
A programok sebessegenek novekedese nem koveti a processzorok sebessegenek
novekedeset.
Udv: Balogh Mihaly
|
+ - | FTP server tukrozese (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Megnyitottam GOPHER-BEER.BKE.HU gopher-, es FTP-BEER.BKE.HU ftp
szerveremet, melyre Anonymous login hasznalataval barkit szivesen latok.
A gepen tukrozom a Slovak Antivirus Center /pub/pc alkonyvtarat
/FTP.ELF.STUBA.SK - a gepemen /pub/sac/pc /, ahol a legujabb antivirus
es archivalo programok megtalalhatok, rengeteg hasznos dolog tarsasagaban.
Az anyagot megprobalom naponta frissiteni, amire nem igazan talaltam
eddig jo megoldast.
Erre szeretnem a segitsegeteket kerni.
Eddig FTP programmal dolgoztam, az egyes alkonyvtarakat atnezve
kimazsolaztam a legujabb datumuakat, majd batch file segitsegevel
lehoztam. A lehozatal ugyan igy automatikus volt, de a szlovak vonal
lassusaga miatt sokaig tart a file-ok kivalogatasa. Arra sem igazan
jottem ra - a konyvtarak atnezese helyett -, hogyan tudnam
kiszurni az eredeti szerveren torolt fajlokat.
A file-ok lehozatalat PC-rol vegzem, hol az FTP programmal, hol
kulonbozo Windows alatt futo FTP programokkal, vagy Minuettel.
Ha ez a modszer "olcsobban" meguszhato Unix gepen, arra is van
lehetosegem, csak nem eppen nagyfoku Unix ismereteimrol vagyok
hires.
A valaszokat maganlevelben is kuldhetitek, amiket elore is
koszonok.
Simon Jozsef
|
+ - | Windows NT + Novell 3.12 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
T. Haalozati GURUk!
Ki tudna nekem sgiteni abban, hogy hogyan lehet a Novell szerverekre
bejelentkezni Windows NT 3.5 alol? Kell hozzaa direkt NT-s Novell
kliens program, vagy eleeg valamit beaallitani? Aki tudja keerem irjon
nekem a cimre.
|
+ - | proba (mind) |
VÁLASZ |
Feladó: (cikkei)
|
zzz
________ __ __ __
/ /| _____ _____ / /| / /| ___ / /|
********/ / /| / /| ** \ ** / / /\ ** |
** | *****/ *****/ ** \ ** / *** \ ** |
** |_____ * |_ * |_ ** ** / * / * \ ** |
**/ /| * //| * //| ** / ******* | ** |
******** | ***/ ***/ ** | * | * | ** |
** | * |___ * |___ ** | * | * | **/
_____** | * / /| * / /| ** | * | * | __
/ ** | *****/ *****/ ** | */ */ / /|
********/ **/ **/
|
+ - | Hatvannyolcezer bit (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Felado :
> Azok a gepek, amik 32 bites cimeken keresztul kepesek a memoriat cimezni,
> azok 32 bitesek, amik nem, azok nem 32 bitesek.
Toled pedig azt kerdeznem: a M68000 hany-bites is akkor? Mivel:
- Regiszterei, aritmetikaja 32-bitesek
- Effektiv cimei 32-bitesek (ugye, ami alapjan te dontesz)
- Valojaban azonban csak 24-biten tud cimezni, mert 24 addr kivezetese van.
(A Motorola hivatalos dokumentacioja ova int attol, hogy a teljes cimekben
emigyen "fennmarado" 8 bitet akarmilyen informacio tarolasara hasznaljuk,
legyen mindig $00 - igazuk van).
Akkor hany bites is a M68000 szerinted?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Szinten >-nak: a PDP-11 cimzesi rendszere a kovetkezo:
XXXXXXXXXXXXXXXX - 16-bites cim
XXXXXXXXXXXXXXXX00 - kiegeszitve 18-ra
XXXXXXXXXXXXXXXXXX0000 - tovabb bovitve 24-re
----------------------
<Effektiv cim>
Ezt a TPA 11/40 kezikonyveben olvastam meg regen. Ugy tudom, a regebbi
sorozatu/tipusu PDP processzoroknal a 24-bitre bovites meg nem volt meg.
Ki meri ezek utan kritizalni a 8086/88 szegmenseltolasat?! ;-)
ERN0
|
+ - | AudioFile (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Szevasztok,
Par napja feldobtam a Sun-unkra a digital AudioFile
(http://www.research.digital.com/CRL/projects/AF/home.html) cuccat.
Hasznalja ezt valaki?
Ugy nez ki, hogy mukodik (arecord, aplay, apass), de mikor a VuSystem
-el teszteltem (http://www.tns.lcs.mit.edu/vs/vusystem.html) csak a
video jott at, hang nem.
Tud valaki segiteni?
Keresek (kozel vagy tavol) partnert is, hogy a rendszer phone-jat ki
tudjam probalni.
----
OS/2 buheraloknak:
Voice Chat for OS/2: http://cjb.ico.net/~dan/voicechat.html
Udv
___________________________________________________
Gergely Galambos http://www.pote.hu/~galambos
..................................................
Computer Department, Medical University of Pecs
Pecs, Szigeti ut 12. H-7624 HUNGARY
voice: +36 72 324122 ext. 1526 fax: +36 72 315864
|
+ - | Hatvannyolcezer-nyolc bit... (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Bocs, ha esetleg ketszer jelennek meg, rendetlenkedik a hiksz gep...
--------
> Felado :
> Azok a gepek, amik 32 bites cimeken keresztul kepesek a memoriat cimezni,
> azok 32 bitesek, amik nem, azok nem 32 bitesek.
Toled pedig azt kerdeznem: a M68000 hany-bites is akkor? Mivel:
- Regiszterei, aritmetikaja 32-bitesek
- Effektiv cimei 32-bitesek (ugye, ami alapjan te dontesz)
- Valojaban azonban csak 24-biten tud cimezni, mert 24 addr kivezetese van.
(A Motorola hivatalos dokumentacioja ova int attol, hogy a teljes cimekben
emigyen "fennmarado" 8 bitet akarmilyen informacio tarolasara hasznaljuk,
legyen mindig $00 - igazuk van).
Akkor hany bites is a M68000 szerinted?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Szinten >-nak: a PDP-11 cimzesi rendszere a kovetkezo:
XXXXXXXXXXXXXXXX - 16-bites cim
XXXXXXXXXXXXXXXX00 - kiegeszitve 18-ra
XXXXXXXXXXXXXXXXXX0000 - tovabb bovitve 24-re
----------------------
<Effektiv cim>
Ezt a TPA 11/40 kezikonyveben olvastam meg regen. Ugy tudom, a regebbi
sorozatu/tipusu PDP processzoroknal a 24-bitre bovites meg nem volt meg.
Ki meri ezek utan kritizalni a 8086/88 szegmenseltolasat?! ;-)
ERN0
|
+ - | Melyen tisztelt GURU! (mind) |
VÁLASZ |
Feladó: (cikkei)
|
A segitsegedet szeretnem kerni az alabbi problema megoldasaban:
Van nekem egy Panasonic RQ-V200 tipusu walkman-em. Radio is van benne.
1993 oktobereben vettem. Volt hozza anno leiras, de elvesztettem. ( az
okos takaritononk kidobta... ).
Egyszer nagyon sokaig nem volt benne elem es elfelejtette a benne levo
beallitasokat. Es arra sehogy sem tudok rajonni, hogy hogyan lehet a
veteli erzekenyseget allitani. Azelott ugy volt, hogy FM -en .2 .1 .05
MHZ es lepesek kozul lehetett valasztani. Most a .2 -es allasban van, es
ez nem tul jo. Sajnos sem a szervizben, sem a markaboltban nem tudtak
segiteni.
Ha esetleg ismered a szukseges gomb-kombinaciot, ird meg legyszi!
Ja, es minden Panasonic/walkman informacioforras cimenek nagyon orulnek!
Elore is koszi!
Gabriel Akos
>From the Technical University of Budapest, Hungary
Department of Electrical Engineering and Informatics
|
+ - | PREHISTORIK 2 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok !
Egy kerdesem volna csupan Valakihez, aki ismeri a PREHISTORIK 2 nevu
jatekot. Hogyan lehet tovabbmenni a kovetkezo szintre, amikor
elerkezem egy VAR felehez, amelybe egy felhuzhato hidon at lehetne
bejutni.Eddig mar eljutottam, de itt a vegen kiir egy szoveget,
melynek lenyege: tobb pontot kell szerezni. / hianyos angoltudasom
szerint legalabbis /
Vagy ez volna a vege ? Remelem nem.
Minden segitseget koeszoenoek.
A valaszokat erre a cimre kerem:
|
+ - | PREHISTORIK 2 (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok !
Egy kerdesem volna csupan Valakihez, aki ismeri a PREHISTORIK 2 nevu
jatekot. Hogyan lehet tovabbmenni a kovetkezo szintre, amikor
elerkezem egy VAR felehez, amelybe egy felhuzhato hidon at lehetne
bejutni.Eddig mar eljutottam, de itt a vegen kiir egy szoveget,
melynek lenyege: tobb pontot kell szerezni. / hianyos angoltudasom
szerint legalabbis /
Vagy ez volna a vege ? Remelem nem.
Minden segitseget koeszoenoek.
A valaszokat erre a cimre kerem:
|
|