Regresar   Cerolag > Foros Generales > Ciencia & Tecnología > Programación

Old 19 Jun 2006, 13:02   #1
s0bamE
Miembro
 
Registrado: Apr 2006
Posts: 265
Predeterminado Es C un lenguaje de bajo nivel?

Bueh, despues de una discusion medio boluda en el foro de Lineage 2 donde se cuestiona al server por estar hecho en Java, salio la discusion sobre si C es de bajo nivel.

Yo estoy convencido de que NO. C es un lenguaje de alto nivel ya que te abstrae de la plataforma, cosa indispensable para hacer codigo portable.

La wikipedia creo me da la razon.
http://en.wikipedia.org/wiki/C_language
Quote:
... in fact C is sometimes referred to (and not always pejoratively) as "high-level assembly" or "portable assembly." It is also sometimes referred to as a mid-level language. ...
http://en.wikipedia.org/wiki/Low-level_language
s0bamE is offline   Citar y responder
Old 19 Jun 2006, 18:42   #2
Dr.D
Advocatus Diaboli
 
Avatar de Dr.D
 
Registrado: Jun 2005
Location: Mi laboratorio secreto
Posts: 4.323
Predeterminado

C no se abstrae nada de la plataforma. Las librerias de C son una lagrima, no tiene multithreading y no tiene sockets. Esas dos cosas hacen que salvo una aplicacion super trivial, C no compile mas que en tu OS.
__________________
Mi laboratorio secreto

NO DOY SOPORTE POR PM DE NADA RELACIONADO CON EL BF1942. USEN EL FORO DE SOPORTE
Dr.D is offline   Citar y responder
Old 20 Jun 2006, 02:35   #3
s0bamE
Miembro
 
Registrado: Apr 2006
Posts: 265
Predeterminado

Quote:
Originalmente publicado por Dr.D
C no se abstrae nada de la plataforma. Las librerias de C son una lagrima, no tiene multithreading y no tiene sockets. Esas dos cosas hacen que salvo una aplicacion super trivial, C no compile mas que en tu OS.

Que no te abstraiga del sistema operativo es una cosa. Y es verdad que el estandar de C no ayuda mucho al respecto.

Pero a mi parecer si te abstrae de la arquitectura, que es lo que lo hace un lenguaje de alto nivel. Digo no necesito entender x86, o sparc o powerpc para programar en C para esas arquitecturas de procesadores.
s0bamE is offline   Citar y responder
Old 20 Jun 2006, 17:56   #4
yodamoo
Miembro
 
Avatar de yodamoo
 
Registrado: Apr 2006
Posts: 540
Predeterminado

Mejor que el pascal es seguro, eso de que sea estructurado es medio choto, cosa que en C no es asi.
yodamoo is offline   Citar y responder
Old 20 Jun 2006, 18:09   #5
Dr.D
Advocatus Diaboli
 
Avatar de Dr.D
 
Registrado: Jun 2005
Location: Mi laboratorio secreto
Posts: 4.323
Predeterminado

er... C es un lenguaje procedural, igual que pascal. No hay diferencias significativas entre los dos mas alla que pascal es fuertemente tipado y C no necesariamente.

@Sobame
Con tu concepto, el unico lenguaje de bajo nivel es assembly o directamente escribir binario. Sin embargo para escribir C si necesitas saber la plataforma, hay varias cosas que solo se pueden hacer conociendo la arquitectura a la que apuntas. Sin ir mas lejos, los problemas de endianness aparecen cada dos por tres cuando laburas con streams en C multiplataforma.
__________________
Mi laboratorio secreto

NO DOY SOPORTE POR PM DE NADA RELACIONADO CON EL BF1942. USEN EL FORO DE SOPORTE
Dr.D is offline   Citar y responder
Old 20 Jun 2006, 19:05   #6
s0bamE
Miembro
 
Registrado: Apr 2006
Posts: 265
Predeterminado

Quote:
Originalmente publicado por Dr.D
Con tu concepto, el unico lenguaje de bajo nivel es assembly o directamente escribir binario. Sin embargo para escribir C si necesitas saber la plataforma, hay varias cosas que solo se pueden hacer conociendo la arquitectura a la que apuntas. Sin ir mas lejos, los problemas de endianness aparecen cada dos por tres cuando laburas con streams en C multiplataforma.

Exacto. Yo creo que los unicos lenguajes de bajo nivel son los assemblers.
Ahora si lo miras desde el otro lado, C no me parece un lenguaje de bajo a nivel al no poder hacerse gran cantidad de cosas, como llamar manejar las interrupciones o las cosas de manejo de memoria. O sea, podes hacer un sistema operativo 100% en C? Yo creo que no.

Acerca de si existe algun lenguage multiplataforma (tanto arquitectura como sistema operativo), creo que no queda ni uno bien parado. Seguro C es uno de los primeros en caer. Pero tampoco te ata tanto a la arquitectura como si lo hace un assembler.
s0bamE is offline   Citar y responder
Old 20 Jun 2006, 19:08   #7
Dr.D
Advocatus Diaboli
 
Avatar de Dr.D
 
Registrado: Jun 2005
Location: Mi laboratorio secreto
Posts: 4.323
Predeterminado

La discusion no tiene sentido la verdad.

Si para vos C es un lenguaje de alto nivel, ¿entonces algo como prolog que es?
__________________
Mi laboratorio secreto

NO DOY SOPORTE POR PM DE NADA RELACIONADO CON EL BF1942. USEN EL FORO DE SOPORTE
Dr.D is offline   Citar y responder
Old 21 Jun 2006, 03:29   #8
s0bamE
Miembro
 
Registrado: Apr 2006
Posts: 265
Predeterminado

Quote:
Originalmente publicado por Dr.D
La discusion no tiene sentido la verdad.

Si para vos C es un lenguaje de alto nivel, ¿entonces algo como prolog que es?

Je! De alto nivel tambien.
s0bamE is offline   Citar y responder
Old 26 Jun 2006, 14:53   #9
Kryp
Miembro
 
Registrado: Jul 2005
Posts: 6
Predeterminado

Bueno, como esta discusion de la que habla s0bamE fue conmigo... (el diciendo q C es de ALTO NIVEL dando una definicion realmente RARA de lo que define el nivel de un lenguaje, y yo diciendo que C es BAJO nivel)...
Como bien te dije en el foro de L2... C es de bajo nivel, podes trabajar con el HARD directamente al igual que ASM... podes hacer ABSOLUTAMENTE todo lo que haces en ASM, podes controlar interrupciones, podes modificar los registros (eax, ebx, edx, etc..) sin la necesidad de escribir codigo ASM (tambien te permite compilar codigo ASM)... C se cambio muchisimo, como bien le dije, se decidio hacerlo menos portable para convertirlo en un lenguaje muchisimo mas potente...
Otra gran barbaridad que este personaje dijo es que lenguajes como el C y ASM se estan muriendo (?!?!?!) y van a morir con el tiempo... este comentario honestamente me dejo totalmente atonito. Pero bueno...
Me canse de explicarle el porque C es un lenguaje de bajo nivel (a mi parecer y el del 100% de los programadores con los que laburo), me termino diciendo que los SHADERS no se pueden programar a bajo nivel (cosa q me dio el pie q JAMAS EN SU VIDA TOCO UN SHADER)...

paso x aca un pequenio codigo mio de hace mas de 6 anios (99') el cual era para presentar en un laburo (utilizo interrupciones en C)...

Code:
// STANDAR VGA CLASS // Coder: Gonzalez Pablo // Desc: Funciones para inicializar video, paletas de colores y dibujar (VERSION C) // La version ASM se encuentra en el archivo (stdvga.asm) #ifndef __STDVGA_H__ #define __STDVGA_H__ #include <mem.h> #include <alloc.h> #include <conio.h> #include <stdio.h> #include <math.h> // MODOS DE VIDEO #define mTEXT 0x0003 // modo TEXTO #define m320x200 0x0013 // modo VGA 320x200 pixels, 256 colores struct PAL{ int r, g, b; }; typedef PAL PALETTE[256]; // ESTRUCTURA DE UN BITMAP struct BITMAP{ unsigned char *data; unsigned int width; unsigned int height; PALETTE palette; }; BITMAP *screen; // apuntador de tipo BITMAP a la pantalla real PALETTE DESKTOP_PAL={0}; PALETTE BW_PAL={0}; PALETTE RED_PAL={0}; PALETTE GREEN_PAL={0}; PALETTE BLUE_PAL={0}; PALETTE RGB_PAL={0}; // ********************************* // * INICIALIZAR MODO DE VIDEO * // ********************************* void vid_mode(int mode){ _asm{ // parte de codigo en ensamblador mov ax, mode // guardar modo en registro AX int 0x10 // llamar a la interrupcion de video } screen->data=(unsigned char far*)0xA0000000; // apuntar al dispositivo de video screen->width=320; screen->height=200; // establecer el ancho y alto de la pantalla } // // ****************************** // * CREAR PANTALLA VIRTUAL * // ****************************** void create_bitmap(BITMAP *bmp, unsigned int width, unsigned int height, const PALETTE palette){ // reservar 64000bytes de memoria para la pantalla virtual if((bmp->data=(unsigned char *)malloc(width*height))!=NULL && (width!=0 || height!=0)){ if(palette!=NULL) *bmp->palette=*palette; else *bmp->palette=*DESKTOP_PAL; bmp->width=width; bmp->height=height; } else bmp=NULL; } // // ********************* // * ESPERAR VSYNC * // ********************* void vSync(void){ // esperar el retrazo vertical del monitor _asm mov dx,0x3DA // uso de codigo ensamblador wait1: asm { in al, dx test al,0x08 jnz wait1 } wait2: _asm { in al, dx test al,0x08 jz wait2 } } // // ********************************* // * LIBERAR MEMORIA UTILIZADA * // ********************************* void free_bmp(BITMAP *bmp){ free(bmp); // liberar memoria bmp=NULL; } // // ************************************** // * ACTIVAR LA PALETA DE UN BITMAP * // ************************************** void set_palette(const BITMAP *bmp){ outp(0x03C6, 0xFF); // borrar la paleta for(register int col=0; col<=255; col++){ outp(0x03C8, col); // elemento numero col outp(0x03C9, bmp->palette[col].r); // guardar el valor R(ed) outp(0x03C9, bmp->palette[col].g); // guardar el valor G(reen) outp(0x03C9, bmp->palette[col].b); // guardar el valor B(lue) } } // // ************************************* // * ACTIVAR LA PALETA DE UN ARRAY * // ************************************* void set_palette(const PALETTE palette){ outp(0x03C6, 0xFF); // borrar la paleta for(register int col=0; col<=255; col++){ outp(0x03C8, col); // elemento numero col outp(0x03C9, palette[col].r); // guardar el valor R(ed) outp(0x03C9, palette[col].g); // guardar el valor G(reen) outp(0x03C9, palette[col].b); // guardar el valor B(lue) } } // // ************************************************** ****** // * TOMAR LA PALETA ACTIVA DEPOSITANDOLA EN UN BITMAP * // ************************************************** ****** void get_palette(BITMAP *bmp){ for(register int col=0; col<=255; col++){ outp(0x03C7, col); // elemento numero col bmp->palette[col].r=inp(0x03C9); // guardar el valor R(ed) bmp->palette[col].g=inp(0x03C9); // guardar el valor G(reen) bmp->palette[col].b=inp(0x03C9); // guardar el valor B(lue) } } // // ************************************************** ***** // * TOMAR LA PALETA ACTIVA DEPOSITANDOLA EN UN ARRAY * // ************************************************** ***** void get_palette(PALETTE palette){ for(register int col=0; col<=255; col++){ outp(0x03C7, col); // elemento numero col palette[col].r=inp(0x03C9); // guardar el valor R(ed) palette[col].g=inp(0x03C9); // guardar el valor G(reen) palette[col].b=inp(0x03C9); // guardar el valor B(lue) } } ... #endif

cualquier duda, la seguimos x aca...

OBSERVAR TODO LO QUE ESTA MARCADO EN NEGRITA....

Editado por Dr.D en 26 Jun 2006 a las 15:18.
Kryp is offline   Citar y responder
Old 26 Jun 2006, 15:15   #10
Dr.D
Advocatus Diaboli
 
Avatar de Dr.D
 
Registrado: Jun 2005
Location: Mi laboratorio secreto
Posts: 4.323
Predeterminado

Te pisaste solito, en ese ejemplo le das la razon a él. Estas usando assembly porque no podes controlar el refresh beat de otro modo.

Para mi los dos estan diciendo ganzadas.
__________________
Mi laboratorio secreto

NO DOY SOPORTE POR PM DE NADA RELACIONADO CON EL BF1942. USEN EL FORO DE SOPORTE

Editado por Dr.D en 26 Jun 2006 a las 15:20.
Dr.D is offline   Citar y responder
Old 26 Jun 2006, 15:42   #11
Kryp
Miembro
 
Registrado: Jul 2005
Posts: 6
Predeterminado

bueno di mi opinion... laburo hace 7 anios en C/C++ y ASM.. se en q laburo (programando juegos y engines 3d) y como laburo (la idea era mostrar outp, inp, register int), en esa epoca para q se den una idea se programaba con DOS4GW para usar resoluciones extendidas(dicho sea de paso era bastante complicadito) :S... me da paja discutir sobre programacion y mas aun semejante pelotudes como el nivel de un lenguaje...
EXTENDED INLINE ASM no es ASM...
Se puede acceder para muchas cosas al HARD con C sin usar ASM...
ci vediamo dopo

Editado por Kryp en 26 Jun 2006 a las 16:25.
Kryp is offline   Citar y responder
Old 26 Jun 2006, 16:36   #12
Dr.D
Advocatus Diaboli
 
Avatar de Dr.D
 
Registrado: Jun 2005
Location: Mi laboratorio secreto
Posts: 4.323
Predeterminado

register int no fuerza un registro, anda y lee la especificacion de C de nuevo, volve y charlamos.

outp no es una funcion de C standard, es una implementacion propietaria que expande a outportb y que a su vez termina siendo una llamada ASM.

Si vas a plantear tu charla como una patoteada tecnica, tene cuidado con lo que decis, porque podes terminar en offside mal.
__________________
Mi laboratorio secreto

NO DOY SOPORTE POR PM DE NADA RELACIONADO CON EL BF1942. USEN EL FORO DE SOPORTE
Dr.D is offline   Citar y responder
Old 26 Jun 2006, 17:05   #13
Kryp
Miembro
 
Registrado: Jul 2005
Posts: 6
Predeterminado

Quote:
Originalmente publicado por Dr.D
register int no fuerza un registro, anda y lee la especificacion de C de nuevo, volve y charlamos.

outp no es una funcion de C standard, es una implementacion propietaria que expande a outportb y que a su vez termina siendo una llamada ASM.

Si vas a plantear tu charla como una patoteada tecnica, tene cuidado con lo que decis, porque podes terminar en offside mal.

wtf? patoteada? buah...
con lo q referia a fuerza (me exprese mal x cierto :S), quise decir que le dice al compilador que en lo posible (el 90% de las veces es un SI) utilice un registro...

Respecto al OUTP se q no es standard de C (jamas dije q lo sea)...
vuelvo a repetir EXTENDED INLINE ASM no es ASM... si nos remitimos a que C no tiene standards para llamar a las interrupciones (en caso de no tomar EIASM como parte de un compilador C), ASM si bien tiene MOV, IRET, INT, etc, es solo un interprete y traduce como C a codigo de maquina (y en todo caso el binario seria el unico interpretado por el HARD directo, por ende el unico lenguaje de bajo nivel seria el binario??)... todo lo q se pueda usar en C sin necesidad de librerias, pertenece al C... asi como todo lo q se usa en ASM sin necesidad de libs, pertenece al ASM... Para mi hoy dia como bien le dije a el, no solo define un lenguaje el nivel segun lo cercano que esta al HARD, sino q ademas lo define la abstraccion que tiene (C no es abstracto para nada)...
se programan microprocesadores y drivers en C...

a eso me referi siempre... y respecto a una patoteada, en ningun momento se me ocurrio... no se xq lo decis.

Editado por Kryp en 26 Jun 2006 a las 17:24.
Kryp is offline   Citar y responder
Old 26 Jun 2006, 20:17   #14
s0bamE
Miembro
 
Registrado: Apr 2006
Posts: 265
Predeterminado

Quote:
Originalmente publicado por Kryp
Para mi hoy dia como bien le dije a el, no solo define un lenguaje el nivel segun lo cercano que esta al HARD, sino q ademas lo define la abstraccion que tiene (C no es abstracto para nada)...
Entonces, definitivamente pensamos diferente de que es un lenguaje de bajo nivel (o de alto nivel). Bajo tur premisas, C es un lenguaje de bajo nivel. Bajo las mias definitivamente no, porque no se puede hacer todo con C. Bajo las de Dr. D, menos que menos, por todo lo que el planteo.
s0bamE is offline   Citar y responder
Old 27 Jun 2006, 02:32   #15
El Hombre Gris
Miembro
 
Registrado: Jun 2006
Posts: 4
Predeterminado

Perdon por la intromisión, creo que puedo colaborar en aclarar la controversia que siempre surge en la categorización de los lenguajes. Segun tengo entendido el despelote original surge de la existencia de dos categorizaciones distintas que historicamente usaron los mismos nombres.

Por un lado se habla de lenguajes de bajo/alto nivel segun la abstraccion del codio maquina que el lenguaje representa. Esta clasificación es en realidad una simplificacion de una clasificacion mas compleja que uso los mismo nombres, utilizada para distinguir la dificultad de crear un compilador para dicho lenguaje. Los lenguajes de alto nivel se caracterizaban por la cantidad de tablas de nombres que debian confeccionar y la complejidad de su generación (considerar el hecho de tener funciones con diferentes scopes de variables), y la complejidad del parseo de las instrucciones (considerar instrucciones con formulas matematicas).

En esta categorizacion el assembler cae definitivamente en la categoria de bajo nivel, pero no asi un lenguaje de assembler con macros (dependiendo de las capacidades de las macros). Aqui es donde difiere con la otra categorizacion. La diferencia fundamental es que la categorización segun complejidad del compilador es relativamente estatica, o sea, no hay margen de duda sobre si un lenguaje pertenece o no a la categoria, en cambio la clasificación sobre el nivel de abstracción tiene limites difusos que dependen del codigo maquina que se tome como punto de partida (consideremos el codigo maquina de la JVM, y podriamos llegar a decir que Java es un lenguaje de bajo nivel).

De todas maneras esta clasificación evolucionó con el advenimiento de los lenguajes estructurados, donde ahora los lenguajes son de nivel 0, nivel 1, nivel 2, nivel 3 e incluso nivel 4. Tambien esta la clasificación generacional que es más bien de caracter cronologico: 1GL (first generation language), 2GL, 3GL, 4GL. Esta ultima tambien suele tener limites difusos y no ser correlativo con la clasificación segun complejidad.
El Hombre Gris is offline   Citar y responder
Old 27 Jun 2006, 04:03   #16
Dr.D
Advocatus Diaboli
 
Avatar de Dr.D
 
Registrado: Jun 2005
Location: Mi laboratorio secreto
Posts: 4.323
Predeterminado

A ver, yo coincido con que C es un lenguaje de bajo nivel comparado con, digamos, Java. Lo que no estoy de acuerdo es con tu afirmacion de que en C podes hacer lo que tengas ganas. Muchas de las librerias de C tienen partes muy extensas escritas en assembler. Que el assembly sea inline es solo una facilidad para no tener que linkear codigo externo, pero no lo vuelve parte del lenguaje. Con ese concepto yo puedo reproducir todo lo que vos haces con tu instruccion ASM en Java, pero eso no va a convertir a Java en un lenguaje de bajo nivel a los ojos de ninguno de nosotros. Delphi, sin ir mas lejos, acepta assembly inline y definitivamente no lo veo como un lenguaje de bajo nivel.
__________________
Mi laboratorio secreto

NO DOY SOPORTE POR PM DE NADA RELACIONADO CON EL BF1942. USEN EL FORO DE SOPORTE
Dr.D is offline   Citar y responder
Old 27 Jun 2006, 12:25   #17
Kryp
Miembro
 
Registrado: Jul 2005
Posts: 6
Predeterminado

Quote:
Originalmente publicado por Dr.D
A ver, yo coincido con que C es un lenguaje de bajo nivel comparado con, digamos, Java. Lo que no estoy de acuerdo es con tu afirmacion de que en C podes hacer lo que tengas ganas. Muchas de las librerias de C tienen partes muy extensas escritas en assembler. Que el assembly sea inline es solo una facilidad para no tener que linkear codigo externo, pero no lo vuelve parte del lenguaje. Con ese concepto yo puedo reproducir todo lo que vos haces con tu instruccion ASM en Java, pero eso no va a convertir a Java en un lenguaje de bajo nivel a los ojos de ninguno de nosotros. Delphi, sin ir mas lejos, acepta assembly inline y definitivamente no lo veo como un lenguaje de bajo nivel.

No no, obviamente q no es de bajo nivel x el eiasm, justamente, x eso para mi hoy dia el nivel de los lenguajes se lo define no solo x cuan cerca del hard esta (ya q hoy dia con inline asm practicamente todos pueden acceder al hard si el OS se los permite) sino x cuan abstracto es... x esas 2 cosas yo considero C un lenguaje de bajo nivel. Y cuando digo que con C se puede hacer todo, me refiero q para hacer cualquier programita que requiera de ASM para hacerlo(un driver, etc), se puede usar C (o sea, no necesitas un compilador ASM y se puede hacer q no sea dependiente del OS obviamente sino mucho sentido no tendria).

Editado por Kryp en 27 Jun 2006 a las 12:32.
Kryp is offline   Citar y responder
Old 27 Jun 2006, 13:58   #18
s0bamE
Miembro
 
Registrado: Apr 2006
Posts: 265
Predeterminado

Quote:
Originalmente publicado por Kryp
No no, obviamente q no es de bajo nivel x el eiasm, justamente, x eso para mi hoy dia el nivel de los lenguajes se lo define no solo x cuan cerca del hard esta (ya q hoy dia con inline asm practicamente todos pueden acceder al hard si el OS se los permite) sino x cuan abstracto es... x esas 2 cosas yo considero C un lenguaje de bajo nivel. Y cuando digo que con C se puede hacer todo, me refiero q para hacer cualquier programita que requiera de ASM para hacerlo(un driver, etc), se puede usar C (o sea, no necesitas un compilador ASM y se puede hacer q no sea dependiente del OS obviamente sino mucho sentido no tendria).
El problema que yo veo es que:
1-Inline assembler no es parte de C. Algunos compiladores lo permiten pero no todos. Microsoft por ejemplo directamente no lo permite en el que viene con la DDK, y es justamente el que se usa para hacer drivers.
2-C y assembler son 2 lenguajes diferentes y creo que diciendo que C tiene "falencias" que podes cubrir con el assembler, es justamente decir no podes lograr que el compilador de C genere cualquier codigo que vos quieras en assembler.
s0bamE is offline   Citar y responder
Responder


Herramientas Buscar en esta discusión
Buscar en esta discusión:

Búsqueda avanzada

Reglas del foro
not puedes iniciar una discusión
not puedes responder a una discusión
not puedes agregar archivos adjuntos
not puedes editar tus posts

El código vB está activado
Emotíconos está activado
El código [IMG] está activado
El código HTML está desactivado
Ir a


Todas las horas son GMT -2. La hora es 13:12.

 
Usando: vBulletin Version 3.5.8
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright © 2007 Cerolag SRL
vRewrite 1.5 beta SEOed URLs completed by Tech Help Forum and Chalo Na.