Hollosi Information eXchange /HIX/
HIX GURU 152
Copyright (C) HIX
1995-06-25
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
1 NT es Novell 3.12 (mind)  15 sor     (cikkei)
2 32 vagy nem 32 bites (mind)  39 sor     (cikkei)
3 Processzor-bitesseg: zarjuk le a vitat! (mind)  87 sor     (cikkei)
4 win95 kacsa!!! (mind)  24 sor     (cikkei)
5 A 32-bitesseg vege (mind)  16 sor     (cikkei)
6 32: kod vs. adat (mind)  30 sor     (cikkei)
7 Fizikai memoria Win32-ben (mind)  68 sor     (cikkei)
8 Re: vegyel linuxot?!? (mind)  30 sor     (cikkei)
9 Re: *** GURU *** #151 (mind)  10 sor     (cikkei)
10 SCO UNIX -hoz AppleTalk ? (mind)  11 sor     (cikkei)

+ - NT es Novell 3.12 (mind) VÁLASZ  Feladó: (cikkei)

Hello mindenkinek, 

Nem kell semmi kulonos a az NT csatlakoztatasahoz. Az NT client jon 
mindenfele meghajtokkal kulonbozo rendszerekhez. Ha van valami tovabbi 
kerdesed kuldj egy uzenetet.

Udvozlettel, 


___,___,________ 
  Laszlo Somi
 San Francisco

                                             
					     
+ - 32 vagy nem 32 bites (mind) VÁLASZ  Feladó: (cikkei)

 irta :

> Memoria eleres lehet 16, 32, 64, 128 etc bit-es, nem ez a meghatarozo.
> A memoria cim nagysaga pedig teljesen lenyegtelen, az csak a cpu altal
> elerheto maximalis cimet (real address) hatarozza meg. Modern gepek virtual
> address-t hasznalnak, ugy hogy ennek nem sok jelentosege van, kiveve hogy
> mekkora memoriat tehetsz a gepbe.

A memoria cim nagysaga egyaltalan nem lenyegtelen, hanem az egyik legfontosabb
adat. Erre referenciakent lasd az altalam egy par regebbi iromanyban emlitett
peldakat (PDP-11, IBM 360). A virtualis memoria pedig maximum csak akkora lehet
,
amennyi adatot meg lehet cimezni.


 irta :

> En meg azt hallottam az eloadomtol annak idejen, hogy az adatbusz szelessege
> hatarozza meg az adott CPU bitszamat, igy Z80, M6510 8 bitesek, 8086,
> 80286 16 bitesek, 80386, 80486 32 bitesek

> Azonban a multiplexeles lassit: ugyanannyi adat kevesebb labon jon ki,
> mintha nem multiplexel a CPU. Peldak multiplexelesre: adat es cim,
> adat also-felso resze, stb.

Szerintem nem az adatbusz szelessege szamit, hanem a cimbusz szelessege.
Tegnap megkerdeztem nehany itteni ember velemenyet is es mind a 3
egyet ertett az en velemenyemmel. Persze ez nem feltetlenul jelenti az
allitas igazsagat, hanem azt, hogy mind a negyunknek volt/van ugyanaz
a tanarja az egyetemen. A multiplexeles lehet, hogy lassabb (persze
nem feltetlenul), de azon nem valtoztat, hogy a processzor hany cimen
levo adatot tud kezelni. Amikor a processzor dobozan levo labakrol
beszelunk, akkor emlekezni kell arra, hogy a lab az csak az interface
a kulso vilagba es nem feltetlenul arul el valamit a processor belso
felepiteserol. Ha valaki nagyon elvetemult, akkor lehet, hogy sikerul
neki egy 3-4 labas 32 bites processzort osszehoznia.


Udv, -- KRisztian
+ - Processzor-bitesseg: zarjuk le a vitat! (mind) VÁLASZ  Feladó: (cikkei)

Kedves GURUk!

Remelem ezzel a levellel hozzajarulok, hogy a regota tarto
"hany bites az x bites mikroprocesszor?" vita vegre lezaruljon. Eddig
harom taborra oszlott a GURU-ba irok velemenye:

Az elso tabor a kulso adatbusz meretet tartja meghatarozonak:
> Mi mar elsoeves informatika eloadason megtanultuk hogy ez a szam
> az ADATBUSZ MERETET jelenti. Ennek pedig a programozo altal
> ...
> vagy:
> 80386SX  16-bites
> 80386(DX) 32-bites (A DX itt annyit tesz: nem SX)
> ...

A masodik szerint a cimbusz szelessege a lenyeges:
> A legjellemzobb (es a szo kvalifikalasa nelkul hasznalt) bitesseg az
> viszont a cim busz szelessege. A tegnapi levelemben, mar leirtam, hogy
> ...

Es a harmadik, aki CPU belso kepessegeihez koti a "bitesseget":
> 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

En ket processzorgyarto (Intel, AMD) sajat velemenyet fogom bemutatni,
es ezzel demonstralni, hogy egyreszt az elso es a harmadik tabornak is
igaza van, masreszt a vitanak nincs sok ertelme.

De eloszor egy-ket adat
(forrasa :
Archive-name: pc-hardware-faq/chiplist/part1
Last-modified: 1995/03/27
Version: 7.4)
-----------------------------------
    2.8.1  Intel i8086A/i80C86A CPU
16 bit internal data bus.
16 bit external data bus.
20 bit address bus.
Data and address bus are multiplexed.

    2.8.2  Intel i8088A/i80C88A CPU
16 bit internal data bus.
8 bit external data bus (can co-operate with all Intel i8085 CPU
                        periphery chips).
20 bit address bus.
Data and address bus are multiplexed.

    2.22.2  Intel i80386SX CPU
32 bit internal data bus.
16 bit external data bus (SX: Single-word eXternal).
24 bit address bus.

    2.22.1  Intel i80386/i80386DX CPU
32 bit internal data bus.
32 bit external data bus (DX: Double-word eXternal).
32 bit address bus.
-------------------
Es akkor az idezetek:
Eloszor egy Intel 386EX leiras (a http://www.intel.com-on elerheto)

Intel386[TM] EX Embedded Microprocessor 

ABSTRACT 
This datasheet describes the Intel386[TM] EX embedded microprocessor. The
Intel386[TM] EX embedded microprocessor is a highly integrated, 32-bit, fully
static CPU with a 16-bit external data bus, a 26-bit external address bus, and
Intel's System Management Mode (SMM). The Intel386[TM] EX microprocessor
..

(azt mar csak en teszem hozza, hogy a fent leirt 32-bites CPU voltakeppen
egy i80386SX.) Intele'k tehat a belso adatbusz szelesseget tekintik
mervadonak.
Es mit mond az AMD (forras: egy regi AMD katalogus, ez volt keznel :-(

AMD 8086: "High performance :-) 16-bit microprocessor"
AMD 8088: "Highly integrated 8-bit microprocessor with 16-bit internal
           structure and 8-bit data-interface"

Azaz AMD-e'kne'l a kulso adatbusz szelessege a meghatarozo.
Konkluzio: az adatbusz szelessege a donto, de az mar gyartotol fugg, hogy a
kulso vagy belso adatbusz szelesseget veszi-e figyelembe. Talan a vitat
ezzel le is zarhatnank. Bocs, ha ha valakinek tul sokszor kellett emiatt
PgDn-t nyomnia ;-).

	Tamas
+ - win95 kacsa!!! (mind) VÁLASZ  Feladó: (cikkei)

Barzi Imre irja:

>>A tegnapi nepszabiban olvastam a szamitastechnikai 'ipar'
>>jelen pillanatban legbiztatobb hiret:

>>oktoberre halasztottak a win95 szallitasat!!!!!!

Elnezest a remhirert, termeszetesen nem igaz, de nem a nepszabi
tevedett, ok csak atvettek a hirt mas hirugynoksegektol, akik szinten 
rosszul tudtak (lam, itt a pelda az ellenorizetlen info tovabbterjesztesenek
helytelen voltarol).

Az eset ugy tortent, hogy az eredetileg augusztusra tervezett japan nyelvu
verziot halasztottak oktoberre, errol irt egy japan hirugynokseg, es megirta
hozza, hogy az eredeti (US) win95 viszont augusztusban jelenik meg. Ezt
az augusztust forditottak (vagy japanra vagy vissza angolra, nem tudom) 
tevesen oktobernek, szoval a nyomda ordoge az oka a tevedesnek.
(Forras: Microsoft)

Elnezest mindenkitol, aki mar pezsgot bontott tegnap!!

Udv,

Imre
+ - A 32-bitesseg vege (mind) VÁLASZ  Feladó: (cikkei)

Tobben irtak a tegnapi GURUban, hogy procik bitesseget az
adatbusz hatarozza meg, ez szerintem is jol hangzik, de en
mindig a belso adatbusz bitjeit (es nem a kivezetett labakat)
fogom megszamolni. Azaz a 386SX sose lesz nalam 16 bites.
Ezt a vitat reszemrol befejezettnek nyilvanitom, mert tul sok
teret kapott mar, holott csak egy elnevezesvita - kb. mint
az a bizonyos i betu. Szoval - miutan mindenki leirta, hogy 
mit gondol - nyugodtan hasznalja a maga altal helyesnek
tartott kifejezest. Ennyi szabadsagot csak megengedhet
maganak az ember.

Azert meg annyit megkerdojeleznek, hogy a Pentium 64-bites-e.

Udv, 

Imre
+ - 32: kod vs. adat (mind) VÁLASZ  Feladó: (cikkei)

 irja:

Az a benyomasom, hogy Kolonits es Barczi elbeszelnek egymas mellett. Zoltan
kicsit hercigeskedik es bajos, apro programocskakrol beszel amit Imre
"industrial  strength" programokkal hasonlit ossze.

>>Imre:
>>> vegyuk eszre, hogy nem a kod,
>>> hanem az adatok swappelese a kritikus. A kod merete ugyanis azert egy
>>> megaba mindig elfer
>>Hm?! Maradjunk abban, hogy van amikor a program nagy, van amikor az adat
>>es van amikor mindketto. (Adatot azert mindig strapasabb swappolni, mert
>>amilyen aljas,  valtozik es ki kell irni. Program bezzeg -nem ugy, mint
>>a regi szep 8-16 bites idokben, ugye Zoltan?- nem irja magat felul.)

Irtam, hogy nem Windows-rol vagy ilyesmirol van szo. Ott tenyleg a kernel maga
is nagyon sok helyet elfoglal. De ha DOS-ra teszel ra 32-bites programot, akkor
az en tapasztalatom szerint mindig sokkal tobb az adat, mint a kod. Lehet
persze ellenpeldat hozni, ahol 20 mega kod van 1 mega adattal, de forditva
konnyebb!!! Szoval ritka a kodtulsulyos alkalmazas.

>>Szoval tobb dolgok vannak... (Talan az Imre altal emlitett C magazinokbol mas
t
>>is kene olvasni, nem csak az editorial-t?)

Ejnye, nem C magazinrol, hanem a c't magazinrol volt szo...

Udv,

Imre
+ - Fizikai memoria Win32-ben (mind) VÁLASZ  Feladó: (cikkei)

Irod:

        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,

Ez a 32 bites driver egy .VXD (Virtual device driver)?

        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?

Igaznak tunik (hozzateszem, hogy nem vagyok driver-szakerto,
csak a kottat olvasom). A dolog szepsegehez tartozik, hogy NT
es Win95 alatt szinte biztos, hogy maskepp nez ki a device-driver
architektura, ugyhogy amit irok, az az NT-re ervenyes.

A driveredben egy Memory Hook-ot kell bejelentened, amit majd
meghiv az NT, amikor az alkalmazas eloszor hivatkozik a hook altal
lefoglalt cimre (onnan veszi eszre, hogy kap egy page fault-ot).
Ekkor meghivhatod a VDDAllocMem-et, aki elerhetove teszi a kert
memoriatartomanyt (megcsinalja a mapping-et), majd megy tovabb az egesz.

A hook-ot a VDDInstallMemoryHook(hVDD, (PVOID)MemoryAddress,
	MIO_PORT_RANGE,
	(PVDD_MEMORY_HANDLER)MyMIOHandler)
hivas allitja be.

MyMIOHandler a kiszolgalo, aki meghivja a

VDDAllocMem( (LPVOID)MIOAddress, PAGE_SIZE, MEM_COMMIT,
	PAGE_READWRITE);
hivast, ezzel bemappeli a memoriat, majd visszater.

Mindez jott a Windows NT device driver kit Win32 Subsystem Driver Design
Guide-bol.

        2, Hogy lehet ugyanezt megcsinalni win3.11/win32s alatt? van 
kernel szintje
        a win32s-nek is, vagy kizarolag win driverrel?

Win32s-nek tudomasom szerint nincs kernel-szintje, az egy csomo VxD,
amik megcsinaljak a lethunkolast (jaj, a szep magyar nyelvnek! ;)
Gyanum az, hogy a VxD-nek ott is mukodnie kellene, persze lehet, hogy
masok a tamogato rutinok.

        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 :)?

Visszakerdezek: melyiket?

Ha van meg kerdesed, keress meg a maszek cimemen.

	Sok sikert
	- Laci

	Gaal Laszlo
	

Standard Disclaimer applies: Itt en beszelek.
+ - Re: vegyel linuxot?!? (mind) VÁLASZ  Feladó: (cikkei)

Kiss Gabor ) irta:
> In article >,  (Madarasz 
Ge
> rgely) writes:
> >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,

> Jo neked, ha hazaig er az NFS! Mekkora savszelesseged ven? 64k? 2M?

Kollegiumi halozat... arcnet is van meg ethernet, az NFSt szolgaltato gep 
az etherneten van, az en gepem az arcneten log, igy a szuk keresztmetszet
2.5 megabit/sec, kulonben a kulso vonalunk csak 56k :-((( ;-)

> >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

> Nem az Infomagic dupla albuma volt az osszes GNU forrassal,
> tsx-11 es sunsite snapshot-tal? Nem olyan sok az.... Csak nem eleg friss.

Ezt nem tudnam pontosan megmondani... nehany honappal ezelott lattam... 
Lehetseges, hogy az volt, de akkor is soknak talalom
Udv. 
                                Gergo

UI. mar tobb csoporttarsam is installalt nalam linuxot, elhoztak a 
winchesteruket, itt meg folraktuk... ok sem vettek CD-t
UUI. a slackware teljes anyaga 100M alatt van!
+ - Re: *** GURU *** #151 (mind) VÁLASZ  Feladó: (cikkei)

On Sat, 24 Jun 1995, Szegedi Krisztian wrote:

> Mi mar elsoeves informatika eloadason megtanultuk hogy ez a szam
> az ADATBUSZ MERETET jelenti. Ennek pedig a programozo

Nem. Azt, hogy hany bites egy proci, abbbol tudhatnok meg, hogy hany
bites az adatregisztere. Ezzel bir ugyanis muveleteket vegezni. Asszem a
tovabbi 'lame war' Folosleges.

#*#*#*#*#*#*#*# E'n, e'n, e'n. E'n. /W. Gombrowicz/ #*#*#*#*#*#*#*#
+ - SCO UNIX -hoz AppleTalk ? (mind) VÁLASZ  Feladó: (cikkei)

Kedves Guruk 

Tud-e valaki segiteni?
Kaptunk kiprobalasra egy SCO UNIX-os gepet. A halozatunk gyakorlatilag csak 
Macintosh gepekbol all. Etherneten TCP/IP-vel el lehet erni, de a kisebb gepek 
a Macintosh sajat LocalTalk protokoljat hasznaljak, es ezek routereken lepnek 
be az ethernetre. A routerek viszont nem ertelmezik a TCP/IP-t, igy az SCO 
UNIX-os gepet nem latjak. Tud-e valaki megoldast?

Kiss Arpad


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