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