🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: es.comp.os.linux.programacion
Article #11654

Puertos [Era: Rutina en ASM]

#11654
From: Xavier Montero
Date: Wed, 24 Oct 2001 21:31
338 lines
17077 bytes
> Lo del tema de los puertos, lo he o�do nombra un par de veces, pero no
> se ha que os refer�s. Yo por puertos tenia entendido los t�picos de Red,
> telnet, ftp, nntp, etc... �Que son estos puertos?, � quiz�s tiene algo
> que ver con svga?

Cuando en un microprocesador (por ejemplo un Z80, un 6510, o un PIC)
ejecutas un programa en c�digo m�quina, pueden suceder dos cosas:
que sea una m�quina Von-Newmann (creo no equivocarme si digo que era
John Von Newmann, 1901-1957) o que no lo sea.

Si es una m�quina de Von-Newmann quiere decir que el programa y
los datos est�n en el mismo bus de direcciones y datos (Z80 y 6510)
y si no es de Von-Newmann los datos y el programa est�n en memorias
f�sicas distintas y se acceden por buses distintos, lo que permite
que puedan ser de medidas distintas (por ejemplo la ROM del PIC
tiene 14 bits de ancho (creo recordar, o 13 quiz�s), mientras que
los datos tienen 8 bits, igual que el Z80 y el 6510.

En los de Von-Newman, tenemos que s�lo un bus direcciona toda la
memoria (ROM de programa, y RAM de datos), y es posible hacer
operaciones del tipo "Suma lo que hay en el registro X del
procesador, a lo que hay en la posici�n de memoria 45".
Para ello el bus de direcciones, tras haber hecho el fetch de
la instrucci�n y descodificarla, coloca la direcci�n "45" en
el bus de direcciones para direccionar la posici�n 45 de la
memoria y poder leer el dato y escribir el resultado.

Pero descodificar una posici�n concreta de memoria era caro
en t�rminos electr�nicos hace a�os. Por ejemplo, si tienes
un direccionamiento de 64K como el Z80, es decir 16 bits de
direcciones, poner unas RAMs de 8K es f�cil, usas los 3 bits
m�s significativos de la direcci�n para saber en cu�l de los
8 bloques de 8K est�s y ya est�. Un simple chip 74LS138
servir� para tal operaci�n, que tiene 3 entradas (en binario)
y 8 salidas (s�lo una activa, la que corresponde al c�digo
binario de la entrada).

En cambio, si tus m�dulos de RAM fueran de 1K, tendr�amos
que dividir uno de los segmentos de 8K en ocho trocitos m�s
peque�os, usando los siguientes 3 bits de direcciones para
saber cu�l de los 8 m�dulos de 1K direccionamos. Pero claro,
necesitar�amos 9 chips 74LS138: 1 para descodificar los bits
15, 14 y 13, y ocho chips para descodificar los bits 12, 11 y
10, uno para cada posible rama de salida del primer
descodificador.

En cualquier caso y ase ve que a medida que el espacio de
direccionamiento se reduce, el sistema de descodificaci�n
aumenta, y eso encarece el sistema (ahora no es aplicable,
sit�ate hace 15 a�os).

Hay muchos dispositivos de entrada/salida que necesitan
apenas 2 o tres posiciones de memoria para funcionar. Por
ejemplo, para un puerto serie podr�amos necesitar 2 � 3 bytes:
En la posici�n X el dato a enviar, en la posici�n X+1 la velocidad
de transmisi�n y en la posici�n X+2 alg�n bit de control de
paridades y dem�s.

Supongamos que tenemos varios chips de este estilo, uno para
el puerto serie, otro para un segundo puerto serie, otro que
controla no-se-qu� de unas interrupciones, otro un puerto
paralelo gen�rico, otro que me mira las teclas de un teclado,
otro que genera imagen (imaginemos s�lo los datos de
configuraci�n de la imagen: resoluci�n, paleta y poco m�s,
imaginemos que la imagen en s� est� en RAM normal) y as�
sucesivamente.

Finalmente, al final del ejercicio de imaginaci�n tendr�s
algo parecido a los ordenadores (l�ase Vic-20s, C64s,
Spectrums, MSXs, etc...) pero tambi�n PCs, Amigas y Macs.

Bien. Si el fabricante desea colocar esos dispositivos
en el espacio de memoria (como el Vic-20 � C64), entonces
puedes tocar los par�metros del hard accediendo a las
posiciones de memoria a saco. Por ejemplo, en el C64, para
cambiar el color de fondo de la pantalla, desde el shell
(o CLI, mejor dicho) se hac�a:

(xxx es el c�digo de color: 0 a 255)
POKE 53281, xxx

Eso es porque el chip VIC (Video Interface Chip) estaba mapeado
entre las posiciones 53248 y 54271 y el registro n�mero 33 (53281
 = 53248 + 33) era el que correspond�a al control del chip que
controlaba el color de fondo de la pantalla.

El registro contiguo, como por ejemplo el 32, estaba en la
posici�n de memoria 53280 (como habr�s podido adivinar) y ese,
mirando en las tablas de especificaci�n del chip, se comprueba
que controla el color de borde de la pantalla.

Toda el espacio de la memoria usado para direccionar chips de
control no estaba disponible para direccionar RAM (salvo
h�biles trucos, que no viene al caso comentar). Como descodificar
era caro (como hemos dicho antes), resulta que no se hac�a una
descodificaci�n correcta. Por ejemplo, f�jate que el espacio
asignado al chip VIC es de 54271 - 53248 = 1023 bytes (curioso?)
y yo no me creo que ese chip, que s�lo ten�a 16 colores y algunos
sprites tuviera 1000 registros por configurar. En realidad
ten�a 53294 - 53248 = 46 registros, con lo que se desaprovechaba
(por ahorrar unas perras en decoders), un total de 1024 - 46 = 
978 posiciones de memoria.

Lo mismo para el chip de sonido y el de no-se-qu� y el de
no-se-cuantos, as� que algunos fabricantes de microprocesadores
decidieron colocar un mapa de memoria especial, de un ancho de
direcciones muy reducido (t�picamente 256 direcciones = 8 bits
de direcciones), especial par colocar ah� todos los
dispositivos que nos apetezca. Por ejemplo, con un solo decoder
de tres bits para dispositivos, podemos segmentar las 256
direcciones en 8 bloques de 32 direcciones. Por ejemplo los
bloques 1 y 2 se asignan al chip de v�deo (y si tiene 46
registros s�lo perdemos 64 - 46 = 18 direcciones, en vez
de las casi mil del ejemplo anterior), y otros chips con
unos pocos registros pueden meterse en un s�lo bloque de
32 direcciones de memoria disponibles.

Esto ten�a 2 ventajas: Reduc�a el coste de los decoders
externos puesto que todo el mecanismo del segundo puerto
estaba integrado en la CPU y adem�s liberaba espacio de
direccionamiento para permitir un acceso a m�s RAM.

Adem�s, este bus de direcciones + su l�nea de control
(I/O-Request en vez de Mem-Request) encarec�a poco la
CPU, pero hubo que dotar al c�digo m�quina y por tanto al
assembler asociado de instrucciones espec�ficas para acceder
a este espacio de direccionamiento. L�giamente, por su
naturaleza no se iban a realizar complicadas operaciones
matem�ticas, era m�s un puerto de entradas y salidas
f�sicas que una zona de almacenamiento de datos as� que
se crey� que con unas pocas instrucciones del tipo
"dato = IN(posici�n)" o "OUT(posici�n, dato)" iba a ser
suficiente.

Como estas conexiones f�sicas se usaban t�picamente para acceder
a puertos f�sicos (paralelos, series, v�deo, etc), el lenguaje
fue derivando en dejar el nombre "posiciones de memoria" para
las posiciones del espacio de direccionamiento del bus al que
se conectaba habitualmente la memoria, el normal, el grande,
mientras que se fue dejando el t�mino "port" o "puerto" para
indicar la posici�n del espacio de direccionamiento
correspondiente a las l�neas que se usaban para conectar puertos.

Por ejemplo, escribe A en la posici�n 100 y escribe A en el port
100 significa, respectivamente, en t�rminos de microprograma:

POKE 100, A

1) Pon 100 en el bus de direcciones de memoria (el grande)
2) Pon A en el bus de datos
3) Notifica que la direcci�n va a ser salida de datos desde la CPU
4) Indica Memory-Request
5) Espera los microsegundos que haga falta
6) Quita Memory-Request
7) Contin�a con el fetch de la siguiente instrucci�n, que ya
   modificar� el bus de direcciones y datos a su manera.

OUT 100, A

1) Pon 100 en el bus de direcciones de entrada/salida (el peque�o)
2) Pon A en el bus de datos
3) Notifica que la direcci�n va a ser salida de datos desde la CPU
4) Indica IO-Request
5) Espera los microsegundos que haga falta
6) Quita IO-Request
7) Contin�a con el fetch de la siguiente instrucci�n, que ya
   modificar� el bus de direcciones y datos a su manera.

Adem�s, en el caso del OUT, algunas CPU como el Z80 sol�an tener
un tiempo de espera en microsegundos m�s elevado que en el caso de
direccionamiento de la memoria, porque el acceso a dispositivos
sol�a tambi�n ser m�s lento que el tiempo necesario para leer
y escribir en RAM. Esta caracter�sitica tambi�n permit�a usar
el puerto sin necesidad de configurar hardware externo para
manipular wait-states entre ciclos para acceso a dispositivos
lentos, ya que siempre eran lentos y punto.

Esta estructura ha durado hasta nuestros d�as. Algunas CPU como
los DSP de Texas Instruments, tienen hasta 4 puertos de acceso, pero
todos igual de r�pidos y todos orientados a memoria. Por ejemplo,
en el mismo ciclo de reloj, mientras hace escribe el resultado de
una operaci�n por un puerto, lee el dato de la siguiente por
otro puerto y hace el fetch de las instrucciones de programa
por un tercer puerto. A�n le sobra un puerto extra para las
operaciones de varios operandos. Por ejemplo, un DSP es capaz de
hacer sumas y multiplicaciones en coma flotante _en el mismo ciclo_
de reloj, porque tiene 2 ALUs (o una ALU muuuuy especial, tanto
como que hace FFT casi solita, pero eso es otro post, je, je)
Esa optimizaci�n es posible si se lee todo desde puertos f�sicos
distintos, y aqu� ha perdido el concepto de "puerto de memoria"
y "puerto de entrada/salida" porque todos son iguales.

En cambio, en estructuras como el PC, que son m�s carcas y birriosas
que yo que s�, todav�a se arrastra (por lo de las compatibilidades
y todo el rollo ese) una estructura de un mapa separado para
i/o respecto el mapa de memoria. As�, en el post original, cuando
seta pone este c�digo:

pushw %%dx\n
pushw %%ax\n
movw %1,%%dx\n
movb %0,%%al\n
out %%al,%%dx\n
popw %%ax\n
popw %%dx"

las instrucciones push y pop acceden a la memoria, en una zona
especial llamada stack, pero que en definitiva es memoria, y
en cambio la instrucci�n "out" referencia al mapa de puertos de
entrada salida, para controlar, como �l dijo en el otro post,
las posiciones del puerto i/o que corresponden al chip que
controla el puerto paralelo.

Como Linux "es as�", un usuario normal, sin que pida permisos
no puede acceder alegremente al mapa de puertos al igual que no
puede acceder al mapa de memoria.

En cambio en un Win98, le toqueteas el puerto paralelo y el
Windows tan pancho. Le da igual. Pero eso es otro cantar. Ahora
con el XP ser� peor: XP debe venir de XPlota si tocas un puerto
o algo as�.

No s� si te he aclarado algo. Si tienes m�s dudas, cons�ltalas.
Como referencia, esta p�gina, que he consultado h�bilmente para
documentar este post:

http://mars.wiwi.uni-halle.de/ec64/technical/project64/memory_maps.html

F�jate que se titula MEMORY maps. No te confunda el hecho de que
en el interior el primer trozo se llame IO Maps. El nombre
correcto ser�a Memory Map used for IO (C64 tenia todas las 
i y las o en el mapa de memoria normal).

En cambio, esta otra:

http://www.komkon.org/fms/MSX/Docs/Portar.txt

es una de los mapas de I/O de MSX. F�jate que mientras las
direcciones de C64 iban de 0000 a FFFF, en el Spectrum iban
de 00 a FF por ser el mapa de i/o peque�ito. Seg�n parece
deber�an hacer un "apa�o" para tener m�s mapa de i/o porque
al final del documento est� documentado que de 0100 a FFFF no
hay nada, pero es l�gico. Si pon�an algo no ser�a accesible
por los que no tienen el apa�o. Vamos, igual de cutre que los
que hacen p�ginas html con flash multimedia, que luego
las ve su p* madre, pero eso ser�a otro post.

En las siguientes tienes el pinout de la 6510 y de la Z80, y
observ�dolas acabar�s de aclarar lo de los ports:

http://www.student.informatik.tu-darmstadt.de/~mjk/nepa/chips/6510.html

y 

http://www.equinox-tech.com/chipdir/giicm/Z80CPU.txt

En el caso del 6510 no hay MREQ sino que la propia l�nea R/-W
controla el proceso. Si el lectura, se supone que la memoria
es suficientemente r�pida y en el siguiente flanco de reloj
se recoge el dato, y para la escritura, -W indica que el
dato est� listo para ser escrito.

En cambio en Z80 hay MREQ y IORQ, que permiten al hard ir a
un lugar o a otro. En el caso del Z80 no es 100% lo que he
comendado de que hay puertos distintos f�sicos, sino que
las mismas l�neas de direcci�n A0 a A7 sirven para la
tanto parte baja de la direcci�n de la memoria como
para la direcci�n completa I/O. Esto es debido a que la
CPU es tanlimitada (por el precio se deduce, je, je, ahora
en las tiendas de electr�nica vale unas 200 ptas), que
no podr�a acceder a la vez a los dos puertos como he
comentado que sucede en los DSPs. As� que si tuviera
dos puertos f�sicos, como los DPSs que tienen varios
puertos f�sicos, ser�a una p�rdida de pins porque mientras
se usaran IOA0 a IOA7 no se usar�an nunca MA0 a MA7 y al
rev�s, as� que decidieron usar las mismas patas.

En cambio para el DSP de Texas Instruments TMS320C30, en:

http://www-s.ti.com/sc/psheets/sprs032a/sprs032a.pdf (800K pero
recomendado)

Vemos un ejemplo de DSP que tiene puertos asim�tricos (es decir, uno
de grande y uno de peque�o) con las patas A0 a A23 y D0 a D31 para
direccionar linealmente (a ver cuando aprenden los PCs sin las
porquer�as de memorias segmentadas en 64K, je, je) 16 millones de
posiciones de 4 bytes cada posici�n. As� mismo, el espacio
de "expansi�n", como le llaman ellos, tiene l�neas de direcci�n
propias llamadas XA0 a XA12 con un bus de datos propios
XD0 a XD31.

Volviendo a la pregunta original, estas direcciones podr�an
llamarse "puertos" por deformaci�n profesional (hist�rica).
Es decir un "nuevo" en el mundo de los microprocesadores
dir� "escribo A en la posici�n B del la memoria" y "escribo
A en la posici�n B de la memoria de expansi�n" mientras que
un "antiguo" dir� "Escribo A en la posici�n B de la memoria"
para el puerto grande y "escribo A en el puerto B" para el
puerto peque�o.

En cambio, ya para rematar la respuesta a tu pregunta, lanzo
otra pregunta:

Sea la docu del modelo superior al anterior: TMS320C40

http://www-s.ti.com/sc/psheets/sprs038/sprs038.pdf
(tambi�n 800K pero creo que vale la pena echarle un ojo)

fij�monos en que nuevamente tiene 2 buses externos (m�s los
internos, pero ahora nos ocupan los externos). El llamado
"global" y el llamado "local" son s�lo dos nombres para dos
buses exactamente iguales entre s�. El global, desde A0 a A30
con datos D0 a D31 (direcciona 2 gigaposiciones de 4 bytes
cada una) y el bus "local" desde LA0 a LA30 con
datos desde LD0 a LD31. Son exactamente iguales...

Qu� pensar� un "nuevo" de un "antiguo" que le llame "puertos"
al bus local y "posiciones de memoria" al bus global?
Probablemente que est� loco! Dir� "pero qu� diferencia hay!?"

Respuesta: Simplemente razones hist�ricas.

Espero que os haya gustado!
Saludos.

PD: Si a alguien le gusta lo que he contado que lo diga... S�lo es
para animarme, al ver el rato que me he pasado para escribir todo
esto s�lo faltar�a que a nadie le importe. Bu�... bu�aa... Ni que
sea que la docu de los DSP os ha molado o que la nostalgia de
los viejos tiempos os ha invadido... Madre m�a! c�mo pasa el
tiempo!!!

Saludines!
Xavi.
-- 
Xavier Montero - Digital Sound Items, scp
Tel: 93 589 71 91 - Fax: 93 590 10 96 - Cell: 630 59 01 62
www.dsitelecom.com - xmontero@dsitelecom.com
Technical Details
Message-ID: <3BD7332C.5A019BFF@dsitelecom.com>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.cwix.com!newsfeed.bcn.ttd.net!news.bcn.ttd.net!frodo.audiolis.com!127.0.0.1!news.antakira.com!not-for-mail
References: <20011013.181001.1931233654.1071@localhost.localdomain> <20011016.074710.327015360.1015@localhost.localdomain> <9qh1f5$b86$1@news.unizar.es> <20011018.013900.863103464.1005@localhost.localdomain> <9qmh9e$o91$1@news.unizar.es> <20011025.002255.674476326.1016@localhost.localdomain> <3BD861C2.94F1509F@teleline.es>

Show Full Headers
Complete Article Headers
X-Google-Language: SPANISH,ASCII
X-Google-Thread: f86c8,e9330a8936f937e0
X-Google-Attributes: gidf86c8,public
X-Google-ArrivalTime: 2001-10-25 15:00:39 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed.cwix.com!newsfeed.bcn.ttd.net!news.bcn.ttd.net!frodo.audiolis.com!127.0.0.1!news.antakira.com!not-for-mail
From: Xavier Montero <xmontero@dsitelecom.com>
Newsgroups: es.comp.os.linux.programacion
Subject: Puertos [Era: Rutina en ASM]
Date: Wed, 24 Oct 2001 23:31:24 +0200
Organization: Digital Sound Items
Lines: 338
Message-ID: <3BD7332C.5A019BFF@dsitelecom.com>
References: <20011013.181001.1931233654.1071@localhost.localdomain> <20011016.074710.327015360.1015@localhost.localdomain> <9qh1f5$b86$1@news.unizar.es> <20011018.013900.863103464.1005@localhost.localdomain> <9qmh9e$o91$1@news.unizar.es> <20011025.002255.674476326.1016@localhost.localdomain> <3BD861C2.94F1509F@teleline.es>
NNTP-Posting-Host: 213.97.227.24
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en