Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #4898 > unrolled thread
| Started by | "io_x" <a@b.c.invalid> |
|---|---|
| First post | 2011-05-28 09:08 +0200 |
| Last post | 2011-05-28 18:42 -0700 |
| Articles | 20 on this page of 139 — 20 participants |
Back to article view | Back to comp.lang.c
for your languages "io_x" <a@b.c.invalid> - 2011-05-28 09:08 +0200
Re: for your languages BGB <cr88192@hotmail.com> - 2011-05-28 02:48 -0700
Re: for your languages "io_x" <a@b.c.invalid> - 2011-05-29 17:51 +0200
Re: for your languages Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-16 15:39 -0700
Re: for your languages "io_x" <a@b.c.invalid> - 2011-06-17 09:55 +0200
Re: for your languages Shao Miller <sha0.miller@gmail.com> - 2011-06-19 22:21 -0500
Re: for your languages "io_x" <a@b.c.invalid> - 2011-06-20 09:51 +0200
Re: for your languages "io_x" <a@b.c.invalid> - 2011-06-20 12:06 +0200
Re: for your languages Shao Miller <sha0.miller@gmail.com> - 2011-06-20 10:08 -0500
Re: for your languages "io_x" <a@b.c.invalid> - 2011-07-08 20:06 +0200
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-28 11:06 +0100
Re: for your languages BGB <cr88192@hotmail.com> - 2011-05-28 03:38 -0700
Re: for your languages "BartC" <bc@freeuk.com> - 2011-05-28 16:01 +0100
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-28 19:36 +0100
Re: for your languages "BartC" <bc@freeuk.com> - 2011-05-28 21:18 +0100
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-29 12:33 +0100
Re: for your languages James Kuyper <jameskuyper@verizon.net> - 2011-05-29 08:31 -0400
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-05-29 05:37 -0700
Re: for your languages James Kuyper <jameskuyper@verizon.net> - 2011-05-29 09:09 -0400
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-05-29 07:00 -0700
Re: for your languages "BartC" <bc@freeuk.com> - 2011-05-29 16:52 +0100
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 02:18 +0100
Re: for your languages James Kuyper <jameskuyper@verizon.net> - 2011-05-30 22:21 -0400
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-05-30 20:39 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-29 12:44 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 02:12 +0100
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-31 10:44 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 02:05 +0100
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-29 12:34 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 02:00 +0100
Re: for your languages "BartC" <bc@freeuk.com> - 2011-05-31 13:10 +0100
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-05-31 06:20 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-31 11:53 -0700
Re: for your languages Angel <angel+news@spamcop.net> - 2011-05-31 12:23 +0000
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 17:46 +0100
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-05-31 17:05 +0000
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-01 15:39 +0100
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-06-01 17:53 +0000
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-02 22:18 +0100
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-06-03 00:44 +0000
Re: for your languages Angel <angel+news@spamcop.net> - 2011-05-31 19:04 +0000
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-01 15:44 +0100
Re: for your languages Angel <angel+news@spamcop.net> - 2011-06-01 19:40 +0000
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-02 21:58 +0100
Re: for your languages Angel <angel+news@spamcop.net> - 2011-06-02 23:09 +0000
Re: for your languages Shao Miller <sha0.miller@gmail.com> - 2011-06-02 21:28 -0500
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-31 10:41 -0700
Re: for your languages Uncle Steve <stevet810@gmail.com> - 2011-05-28 11:15 -0400
Re: for your languages Lorenzo Villari <vlllnz@tiscali.it> - 2011-05-28 20:05 +0200
Re: for your languages Uncle Steve <stevet810@gmail.com> - 2011-05-28 14:16 -0400
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-28 12:07 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-29 12:19 +0100
Re: for your languages James Kuyper <jameskuyper@verizon.net> - 2011-05-29 08:59 -0400
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 01:50 +0100
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-05-29 20:36 +0000
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 00:28 +0100
Re: for your languages Michael Press <rubrum@pacbell.net> - 2011-05-30 17:21 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 01:58 +0100
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-05-31 01:27 +0000
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-31 10:37 -0700
Re: for your languages Michael Press <rubrum@pacbell.net> - 2011-05-31 18:34 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-01 15:06 +0100
Re: for your languages James Kuyper <jameskuyper@verizon.net> - 2011-06-01 10:30 -0400
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-02 21:36 +0100
Re: for your languages James Kuyper <jameskuyper@verizon.net> - 2011-06-02 22:06 -0400
Re: for your languages Michael Press <rubrum@pacbell.net> - 2011-06-01 18:19 -0700
Re: for your languages Shao Miller <sha0.miller@gmail.com> - 2011-06-02 01:06 -0500
Re: for your languages Michael Press <rubrum@pacbell.net> - 2011-06-03 12:02 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-02 21:34 +0100
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-02 15:53 -0700
Re: for your languages Michael Press <rubrum@pacbell.net> - 2011-06-03 12:24 -0700
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-05-31 01:10 +0000
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-31 10:34 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-01 14:58 +0100
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-02 21:18 +0100
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-02 13:40 -0700
Re: for your languages Billy Mays <noway@nohow.com> - 2011-06-02 17:31 -0400
Re: for your languages Michael Press <rubrum@pacbell.net> - 2011-06-03 10:39 -0700
Re: for your languages James Kuyper <jameskuyper@verizon.net> - 2011-06-02 22:19 -0400
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-06-02 19:36 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-03 08:44 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-04 14:41 +0100
Re: for your languages Angel <angel+news@spamcop.net> - 2011-06-04 16:31 +0000
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-04 09:51 -0700
Re: for your languages Angel <angel+news@spamcop.net> - 2011-06-05 00:05 +0000
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-06-04 18:31 -0700
Re: for your languages "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-04 10:02 -0700
Re: for your languages cri@tiac.net (Richard Harter) - 2011-06-04 22:10 +0000
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-06-04 18:26 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-05 13:40 +0100
Re: for your languages Angel <angel+news@spamcop.net> - 2011-06-05 15:47 +0000
Re: for your languages "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-05 10:16 -0700
Re: for your languages "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-05 10:30 -0700
Re: for your languages Heikki Kallasjoki <see@end.of.message.invalid> - 2011-06-05 17:38 +0000
Re: for your languages "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-05 10:49 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-04 09:50 -0700
Re: for your languages Michael Press <rubrum@pacbell.net> - 2011-06-04 13:23 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-05 12:32 +0100
Re: for your languages "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-05 07:15 -0700
Re: for your languages "io_x" <a@b.c.invalid> - 2011-06-06 18:18 +0200
Re: for your languages "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 11:40 -0700
Re: for your languages "io_x" <a@b.c.invalid> - 2011-06-07 16:57 +0200
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-07 08:36 -0700
Re: for your languages "io_x" <a@b.c.invalid> - 2011-06-07 18:19 +0200
Re: for your languages "io_x" <a@b.c.invalid> - 2011-06-07 18:32 +0200
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-05 12:33 -0700
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-06-05 13:08 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-05 13:54 -0700
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-06-05 18:57 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-05 20:37 -0700
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-06-05 20:58 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-05 21:49 -0700
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-06-05 22:05 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-06 09:11 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-16 13:00 -0700
Re: for your languages Michael Press <rubrum@pacbell.net> - 2011-06-06 02:04 -0700
Re: for your languages "BartC" <bc@freeuk.com> - 2011-06-06 10:21 +0100
Re: for your languages "BartC" <bc@freeuk.com> - 2011-06-05 22:47 +0100
Re: for your languages China Blue Angels <chine.bleu@yahoo.com> - 2011-06-05 18:25 -0700
Re: for your languages Ian Collins <ian-news@hotmail.com> - 2011-06-06 13:41 +1200
Re: for your languages "BartC" <bc@freeuk.com> - 2011-06-06 10:06 +0100
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-06-06 15:39 +0000
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-06-06 15:39 +0000
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 00:44 +0100
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-05-31 18:09 +0100
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-31 12:00 -0700
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-01 15:33 +0100
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-01 09:07 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-06-01 10:12 -0700
Re: for your languages BGB <cr88192@hotmail.com> - 2011-06-01 12:45 -0700
Re: for your languages "BartC" <bc@freeuk.com> - 2011-06-03 15:41 +0100
Re: for your languages Rui Maciel <rui.maciel@gmail.com> - 2011-06-05 13:30 +0100
Re: for your languages Seebs <usenet-nospam@seebs.net> - 2011-06-06 15:39 +0000
Re: for your languages "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-28 03:34 -0700
Re: for your languages "io_x" <a@b.c.invalid> - 2011-05-29 08:42 +0200
Re: for your languages Anders Wegge Keller <wegge@wegge.dk> - 2011-05-29 01:00 +0200
Re: for your languages Angel <angel+news@spamcop.net> - 2011-05-28 23:49 +0000
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-28 18:42 -0700
Re: for your languages Keith Thompson <kst-u@mib.org> - 2011-05-28 18:42 -0700
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Angel <angel+news@spamcop.net> |
|---|---|
| Date | 2011-05-31 19:04 +0000 |
| Message-ID | <slrniuaet4.la0.angel+news@pearlgates.net> |
| In reply to | #5120 |
On 2011-05-31, Rui Maciel <rui.maciel@gmail.com> wrote:
>
> If you compile a C compiler with a compiler that only supports a single
> architecture then that particular program, compiled by that compiler, will
> work only on that architecture. Conversely, if you compile an assembly
> program with a compiler which just so happens to support other
> architectures, whether by transliterating or by using some sort of
> intermediate form, then that program written in assembly will behave the
> same whether it is compiled for any architecture which is supported by the
> compiler.
>
> That is, what the language is and what the compiler does are two different
> and completely distinct things.
This is "hello world" in C:
#include <stdio.h>
int main(void)
{
printf("Hello world!\n");
}
It will work without modification on virtually any architecture with a
reasonably standards-compliant C compiler.
Now here is the same "hello world" in assembler:
.file "hello.c"
.section .rodata
.LC0:
.string "Hello world!"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
movq %rsp, %rbp
.cfi_offset 6, -16
.cfi_def_cfa_register 6
movl $.LC0, %edi
call puts
leave
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5"
.section .note.GNU-stack,"",@progbits
Let's see you get it to work on something that isn't x86 or compatible,
without changing a letter of the program.
Here is, for example, the result on a Sparc64:
gcc -o hello hello.s
hello.s: Assembler messages:
hello.s:11: Error: Unknown opcode: `pushq'
hello.s:13: Error: Unknown opcode: `movq'
hello.s:16: Error: Illegal operands
hello.s:18: Error: Unknown opcode: `leave'
Now imagine how the situation for a non-trivial program would be.
--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-06-01 15:44 +0100 |
| Message-ID | <4de65067$0$16787$a729d347@news.telepac.pt> |
| In reply to | #5142 |
Angel wrote:
> This is "hello world" in C:
>
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("Hello world!\n");
> }
>
> It will work without modification on virtually any architecture with a
> reasonably standards-compliant C compiler.
>
>
> Now here is the same "hello world" in assembler:
>
>
> .file "hello.c"
> .section .rodata
> .LC0:
> .string "Hello world!"
> .text
> .globl main
> .type main, @function
> main:
> .LFB0:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> movq %rsp, %rbp
> .cfi_offset 6, -16
> .cfi_def_cfa_register 6
> movl $.LC0, %edi
> call puts
> leave
> ret
> .cfi_endproc
> .LFE0:
> .size main, .-main
> .ident "GCC: (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5"
> .section .note.GNU-stack,"",@progbits
>
> Let's see you get it to work on something that isn't x86 or compatible,
> without changing a letter of the program.
>
> Here is, for example, the result on a Sparc64:
> gcc -o hello hello.s
> hello.s: Assembler messages:
> hello.s:11: Error: Unknown opcode: `pushq'
> hello.s:13: Error: Unknown opcode: `movq'
> hello.s:16: Error: Illegal operands
> hello.s:18: Error: Unknown opcode: `leave'
>
>
> Now imagine how the situation for a non-trivial program would be.
You've presented a compiler error caused by an attempt to compile code
which wasn't supported by that compiler. If I try to compile Pascal code
with gcc I will also get a bunch of error messages. Yet, that doesn't
mean that it isn't possible to compile Pascal code on your platform.
If, instead, you tried to compile it with a compiler which supported that
programming language then obviously it would work. This applies to both
the Pascal Vs C example and your x86 Vs Sparc64 example.
Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Angel <angel+news@spamcop.net> |
|---|---|
| Date | 2011-06-01 19:40 +0000 |
| Message-ID | <slrniud5de.31d.angel+news@pearlgates.net> |
| In reply to | #5190 |
On 2011-06-01, Rui Maciel <rui.maciel@gmail.com> wrote: >> >> Let's see you get it to work on something that isn't x86 or compatible, >> without changing a letter of the program. >> >> Here is, for example, the result on a Sparc64: >> gcc -o hello hello.s >> hello.s: Assembler messages: >> hello.s:11: Error: Unknown opcode: `pushq' >> hello.s:13: Error: Unknown opcode: `movq' >> hello.s:16: Error: Illegal operands >> hello.s:18: Error: Unknown opcode: `leave' >> >> >> Now imagine how the situation for a non-trivial program would be. > > You've presented a compiler error caused by an attempt to compile code > which wasn't supported by that compiler. If I try to compile Pascal code > with gcc I will also get a bunch of error messages. Yet, that doesn't > mean that it isn't possible to compile Pascal code on your platform. gcc on Sparc *does* understand assembler *which is written for Sparc*, which is exactly my whole point. An assembly language specifies machine code, which will *only* work on the architecture it was written for. C on the other hand, is architecture independent. It's a higher level of abstraction, C is a third generation language while assembly is a second generation one. There is much more to that than what macros can solve. > If, instead, you tried to compile it with a compiler which supported that > programming language then obviously it would work. This applies to both > the Pascal Vs C example and your x86 Vs Sparc64 example. Then explain please, why the C program works unmodified on both Sparc and x86, while the assembly program does not? Let me clue you in, there is *no* assembler in the world that can make that program work unmodified on Sparc64. -- "C provides a programmer with more than enough rope to hang himself. C++ provides a firing squad, blindfold and last cigarette." - seen in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-06-02 21:58 +0100 |
| Message-ID | <4de7f966$0$8879$a729d347@news.telepac.pt> |
| In reply to | #5222 |
Angel wrote: > gcc on Sparc *does* understand assembler *which is written for Sparc*, > which is exactly my whole point. An assembly language specifies machine > code, which will *only* work on the architecture it was written for. Indeed. And that detail means that sparc assembly is not the same programming language as x86 assembly. Therefore, trying to compile a program writen in language foo with a compiler for language bar is a task clearly not destined to succeed, whether foo is pascal/x86 assembly and bar is C/sparc assembly. Yet, if you compile language foo with a compiler for language bar then naturally there wouldn't be a problem. > C on the other hand, is architecture independent. It's a higher level of > abstraction, C is a third generation language while assembly is a second > generation one. There is much more to that than what macros can solve. The issue is not how different the levels of abstraction are. No one claimed that C's level of abstraction isn't higher than any level of abstraction employed in any assembly language. The issue being discussed is that all programming languages are in essence macro-assembly languages of sorts. That is, the level of abstraction, once it's there, may vary significantly among languages but those languages end up serving the exact same purpose: a way to specify statements which can be mapped to opcode. >> If, instead, you tried to compile it with a compiler which supported >> that programming language then obviously it would work. This applies >> to both the Pascal Vs C example and your x86 Vs Sparc64 example. > > Then explain please, why the C program works unmodified on both Sparc > and x86, while the assembly program does not? Well, sparc assembly isn't the same language as x86 assembly. > Let me clue you in, there is *no* assembler in the world that can make > that program work unmodified on Sparc64. That may be true, as I don't believe there is a high demand for a tool that performs that task. If there was then it is quite obvious that it would be far from impossible to write it. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Angel <angel+news@spamcop.net> |
|---|---|
| Date | 2011-06-02 23:09 +0000 |
| Message-ID | <slrniug622.k9q.angel+news@pearlgates.net> |
| In reply to | #5301 |
On 2011-06-02, Rui Maciel <rui.maciel@gmail.com> wrote: > Angel wrote: > >> gcc on Sparc *does* understand assembler *which is written for Sparc*, >> which is exactly my whole point. An assembly language specifies machine >> code, which will *only* work on the architecture it was written for. > > Indeed. And that detail means that sparc assembly is not the same > programming language as x86 assembly. Therefore, trying to compile a > program writen in language foo with a compiler for language bar is a task > clearly not destined to succeed, whether foo is pascal/x86 assembly and > bar is C/sparc assembly. Except for the little fact there is no such thing as "Pascal assembly" or "C assembly", and a correctly written Pascal or C program *does* work as specified regardless of whether the underlying architecture is Intel or Sparc. (Unless of course it does something that is impossible or makes no sense on the target architecture.) Also, it's not even the hardware so much. An assembly program written for DOS will most likely not work on Linux or OS/2. > Yet, if you compile language foo with a compiler for language bar then > naturally there wouldn't be a problem. And yet it is in most cases fairly trivial to make a C program written for one compiler work under another, as long as both compilers support the standard. >> C on the other hand, is architecture independent. It's a higher level of >> abstraction, C is a third generation language while assembly is a second >> generation one. There is much more to that than what macros can solve. > > The issue is not how different the levels of abstraction are. No one > claimed that C's level of abstraction isn't higher than any level of > abstraction employed in any assembly language. The issue being discussed > is that all programming languages are in essence macro-assembly languages > of sorts. That is, the level of abstraction, once it's there, may vary > significantly among languages but those languages end up serving the exact > same purpose: a way to specify statements which can be mapped to opcode. Then go ahead and map the statement a = b; to an opcode. Go on, we're waiting. Saying "all languages are in essence macro-assembly languages" is a very crude and overly broad simplification that shows you actually know very little about how a compiler works and what sorts of problems it has to deal with. The only thing that is true is that both a compiler and an assembler eventually output something that can be understand by the machine, but the processes by which they get there are quite different. >> Let me clue you in, there is *no* assembler in the world that can make >> that program work unmodified on Sparc64. > > That may be true, as I don't believe there is a high demand for a tool > that performs that task. If there was then it is quite obvious that it > would be far from impossible to write it. No it is impossible to write such assembler, because as you have stated above yourself it is x86 assembler, specifing a machine code that the Sparc simply does not understand. You could perhaps write a program that translates it to Sparc assembler that functions in a similar way, although I'm afraid you'll find that a lot harder than you seem to think. And regardless, what you have written then is not an assembler. A second generation language maps instructions directly to opcodes, a third generation language does not. -- "C provides a programmer with more than enough rope to hang himself. C++ provides a firing squad, blindfold and last cigarette." - seen in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-06-02 21:28 -0500 |
| Message-ID | <is9dbt$r56$1@dont-email.me> |
| In reply to | #5301 |
On 6/2/2011 3:58 PM, Rui Maciel wrote: > The issue is not how different the levels of abstraction are. No one > claimed that C's level of abstraction isn't higher than any level of > abstraction employed in any assembly language. The issue being discussed > is that all programming languages are in essence macro-assembly languages > of sorts. That is, the level of abstraction, once it's there, may vary > significantly among languages but those languages end up serving the exact > same purpose: a way to specify statements which can be mapped to opcode. > On 6/2/2011 1:06 AM, Shao Miller wrote: > Would it be useful to pretend that the C language specifies a > "macro-assembly" translation procedure where the final, translated > elements are a sequence of values which specify behaviour, which can > then, optionally, further be translated again into machine instructions? > > Or instead of behaviour, perhaps a sequence of values which specify > implementation considerations, which can then, optionally, further be > translated again into machine instructions? > > Just kidding. :) Or not. :) To be honest, I'd really enjoy a sample implementation of a "C byte-code" whose scope is as close to a Standard C as possible (and no, not a source file, heh). Even better would be if the byte-code could be translated "back up" and resemble the original source, perhaps minus comments and whitespace detail.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-31 10:41 -0700 |
| Message-ID | <lnsjrupy2s.fsf@nuthaus.mib.org> |
| In reply to | #5069 |
Rui Maciel <rui.maciel@gmail.com> writes:
> Keith Thompson wrote:
>> Oh, did we mention that a and b are both multi-kilobyte structures?
>> And that the target CPU doesn't have a MOV instruction?
>
> Would that made it impossible to generate assembly code for those cases?
No, of course not. It merely means that it would generate *different*
assembly code. The C language input doesn't specify which assembly code
is generated.
The output is assembly code; the input is not.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-28 11:15 -0400 |
| Message-ID | <2f833863e4109a6-ba5a3@gmail.com> |
| In reply to | #4903 |
On Sat, May 28, 2011 at 11:06:30AM +0100, Rui Maciel wrote: > io_x wrote: > > > are you sure your langages are better than some type of macro-assembly? > > I would say that all high level programming languages are macro-assembly > languages of sorts, varying in their level of abstraction and how their > macros are implemented and handled. OO representations are a lot of work in C, but the language isn't designed to make OO tasks convenient by way of some abbreviated syntax. ASM is even worse. I enjoy using C for several reasons, not the least of which is its near-asm performance with optimizing compilers. The simple abstract numerical model of arithmetic in C makes 99% of mathematical expressions simple to write, e.g.: a = b + sqrt(c) -- no messy syntax. Input and output file operations are convenient enough to use for scripting purposes, and in general the C-library has everything you might need for 99% of the software you might have to write. ASM is non-portable by definition, so regardless of the size of your macro-library, it's usefulness is tied to the life of the platform. There must be tons of good code and algorithms lost forever because they were written for a specific platform that was succeeded by something with a different instruction set. C gets you just far enough away from the hardware to make portability feasible, reducing all that otherwise wasted effort. Genetic programming or artificial intelligence research might not be very nice to do in C, but for those problems we have OO languages, and you really don't want macro assembler for that. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Lorenzo Villari <vlllnz@tiscali.it> |
|---|---|
| Date | 2011-05-28 20:05 +0200 |
| Message-ID | <20110528200520.5b4b5274@kubuntu> |
| In reply to | #4913 |
On Sat, 28 May 2011 11:15:18 -0400 Uncle Steve <stevet810@gmail.com> wrote: > > Genetic programming or artificial intelligence research might not be > very nice to do in C, > Why?
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-28 14:16 -0400 |
| Message-ID | <750cfdd58b2f824-9096d@gmail.com> |
| In reply to | #4914 |
On Sat, May 28, 2011 at 08:05:20PM +0200, Lorenzo Villari wrote: > On Sat, 28 May 2011 11:15:18 -0400 > Uncle Steve <stevet810@gmail.com> wrote: > > > > > Genetic programming or artificial intelligence research might not be > > very nice to do in C, > > Why? I haven't tried to, if that's what you're asking. I can just sort-of envision what it is that AI programmers do from the little literature I've skimmed, and I can't imagine doing that stuff in C. I think you'd have to be a robot to do it successfully. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-28 12:07 -0700 |
| Message-ID | <lnlixqtzjf.fsf@nuthaus.mib.org> |
| In reply to | #4903 |
Rui Maciel <rui.maciel@gmail.com> writes:
> io_x wrote:
>> are you sure your langages are better than some type of macro-assembly?
>
> I would say that all high level programming languages are macro-assembly
> languages of sorts, varying in their level of abstraction and how their
> macros are implemented and handled.
I would say that you're ignoring the meaning of "macro-assembly".
A program in a macro-assembly language specifies (perhaps indirectly in
some cases) the CPU instructions to be generated. A program in a high
level language, including C, specifies behavior.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-05-29 12:19 +0100 |
| Message-ID | <4de22bd1$0$16159$a729d347@news.telepac.pt> |
| In reply to | #4918 |
Keith Thompson wrote: > I would say that you're ignoring the meaning of "macro-assembly". > > A program in a macro-assembly language specifies (perhaps indirectly in > some cases) the CPU instructions to be generated. A program in a high > level language, including C, specifies behavior. ...which also specifies the CPU instructions that are generated from the source code, although it may not do that in a bijective way and it may vary with the degree of abstraction. To put it differently, once you recognize and accept the "indirectly" bit, the distinction between the compiler of a macro language and the compiler of a high-level programming language amounts to nit-picking regarding how much optimization it may or may not employ, which is a discussion of how much grey is supposed to be grey. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-29 08:59 -0400 |
| Message-ID | <irtg0a$83o$1@dont-email.me> |
| In reply to | #4999 |
On 05/29/2011 07:19 AM, Rui Maciel wrote: > Keith Thompson wrote: > >> I would say that you're ignoring the meaning of "macro-assembly". >> >> A program in a macro-assembly language specifies (perhaps indirectly in >> some cases) the CPU instructions to be generated. A program in a high >> level language, including C, specifies behavior. > > ...which also specifies the CPU instructions that are generated from the > source code, although it may not do that in a bijective way and it may > vary with the degree of abstraction. I think that, by dropping bijectivity, you've also dropped the ability to use the word "specifies". Standard C doesn't provide any method for me to tell the compiler which "specific" instructions to use (though many implementations provide the 'asm' statement as an extension). I can only define the desired behavior, and the compiler is free to use any set of instructions that produces that same behavior; there's nothing "specific" about that relationship between the behavior and the resulting set of instructions. > ... To put it differently, once you > recognize and accept the "indirectly" bit, the distinction between the > compiler of a macro language and the compiler of a high-level programming > language amounts to nit-picking regarding how much optimization it may or > may not employ, which is a discussion of how much grey is supposed to be > grey. You can make any two things fit into the same category, by ignoring all of the distinctions between them. However, a macro assembler not only allows you to specify particular instructions; it requires you to do so. An HLL compiler does neither. That's a pretty important distinction to be ignoring. It is not a purely quantitative one, it's a very real qualitative one. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-05-31 01:50 +0100 |
| Message-ID | <4de43b68$0$16778$a729d347@news.telepac.pt> |
| In reply to | #5005 |
James Kuyper wrote: > I think that, by dropping bijectivity, you've also dropped the ability > to use the word "specifies". Standard C doesn't provide any method for > me to tell the compiler which "specific" instructions to use (though > many implementations provide the 'asm' statement as an extension). This is irrelevant. If you compile your code with a compiler which doesn't perform any optimization whatsoever and is able to bijectively map C code to object code then, although the standard doesn't specify anything regarding this, you are able to tell exactly what object code you are generating from a set of C statements. This means that you are able to tell the compiler exactly which instructions to dump. It may not be as expressive as using an assembly language but you are still specifying what object code should be dumped. > I can > only define the desired behavior, and the compiler is free to use any > set of instructions that produces that same behavior; there's nothing > "specific" about that relationship between the behavior and the > resulting set of instructions. If you write code using an assembly language which supports macros and you write your code based on those macros (and therefore you would be writing your assembly code by defining desired behaviour instead of specific instructions) then would that mean that this macro-assembly language is suddenly not a macro-assemblly language anymore? > You can make any two things fit into the same category, by ignoring all > of the distinctions between them. However, a macro assembler not only > allows you to specify particular instructions; it requires you to do so. If you happen to use a pre-defined macro on a program written in a assembly language then how exactly were you required to specify those instructions? And if you develop a program in assembly based on macros which you didn't develop yourself nor you want to waste your time checking then does that mean that that particular macro-assembly language isn't a macro-assembly language? And if you have a bijective map between C code and object code then will the ability to specify exactly which set of instructions your code generates make the C programming language a macro- assembly language? Knowing this, there is a reason why they are placed in the same category. You need to intentionally ignore the fundamental definition of that category to be unable to include them in it. > An HLL compiler does neither. That's a pretty important distinction to > be ignoring. It is not a purely quantitative one, it's a very real > qualitative one. You are confusing the compiler with the language and the language with the compiler, which may explain your confusion regarding this subject. To clear this for you, answer this: if I compile assembly code with a compiler which performs any form of optimization (and therefore we lose the ability to "specify particular instructions") then does that mean that that particular assembly language ceasses to be an assembly language? And if we compile C code with a compiler which doesn't perform any optimization and bijectively maps C code to object code then, by using expressions which we know are mapped to single instructions (for example, i++) then would that mean that C is suddenly an assembly language? And would that mean that the level of a particular programming language depends on the amount of optimization that it employs? Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-29 20:36 +0000 |
| Message-ID | <slrniu5518.1vua.usenet-nospam@guild.seebs.net> |
| In reply to | #4999 |
On 2011-05-29, Rui Maciel <rui.maciel@gmail.com> wrote: > ...which also specifies the CPU instructions that are generated from the > source code, although it may not do that in a bijective way and it may > vary with the degree of abstraction. To put it differently, once you > recognize and accept the "indirectly" bit, the distinction between the > compiler of a macro language and the compiler of a high-level programming > language amounts to nit-picking regarding how much optimization it may or > may not employ, which is a discussion of how much grey is supposed to be > grey. I don't think I buy that. Macro assemblers are still fundamentally manipulating stuff which is basically tied to the CPU architecture. Whether the machine has one general purpose register or 128 will affect the code you write. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-05-31 00:28 +0100 |
| Message-ID | <4de42836$0$16796$a729d347@news.telepac.pt> |
| In reply to | #5022 |
Seebs wrote: > I don't think I buy that. Macro assemblers are still fundamentally > manipulating stuff which is basically tied to the CPU architecture. > Whether the machine has one general purpose register or 128 will affect > the code you write. Let's put it this way: we develop a C compiler which performs no optimization whatsoever and therefore is able to bijectively map C code to code in any other lower level language, which may be an assembly language or even object code. If that map only covers a specific CPU architecture, and therefore it is basically tied to that particular CPU architecture, does that mean that this particular hypothetical compiler is a macro assembler? Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-30 17:21 -0700 |
| Message-ID | <rubrum-AAC8BA.17212030052011@news.albasani.net> |
| In reply to | #5062 |
In article <4de42836$0$16796$a729d347@news.telepac.pt>, Rui Maciel <rui.maciel@gmail.com> wrote: > Seebs wrote: > > > I don't think I buy that. Macro assemblers are still fundamentally > > manipulating stuff which is basically tied to the CPU architecture. > > Whether the machine has one general purpose register or 128 will affect > > the code you write. > > Let's put it this way: we develop a C compiler which performs no > optimization whatsoever and therefore is able to bijectively map C code to > code in any other lower level language, which may be an assembly language > or even object code. If that map only covers a specific CPU architecture, > and therefore it is basically tied to that particular CPU architecture, > does that mean that this particular hypothetical compiler is a macro > assembler? The author of a program for a macro assembler knows exactly what machine instructions will be produced from his program. This is not the case for the author of a C program. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2011-05-31 01:58 +0100 |
| Message-ID | <4de43d29$0$16782$a729d347@news.telepac.pt> |
| In reply to | #5064 |
Michael Press wrote: > The author of a program for a macro assembler > knows exactly what machine instructions will be > produced from his program. If he uses macros, either pre-defined ones or macros which he didn't write, then he doesn't know what machine instructions will be produced by his program. If he compiles his assembly code with a compiler which performs any form of code optimization then he doesn't know what machine instructions will be produced by his program. And yet, the language never ceassed to be assembly. Conversely, if we have a compiler which bijectively maps C code to object code and if a programmer writes C code with that particular compiler in mind then he is able to know exactly what assembly code will be generated from his code. And yet, the language never ceassed to be C. > This is not the > case for the author of a C program. As I've demonstrated above, it can be the case for the author of an C program and it may not be the case for the author of an assembly program. The compiler isn't the language and the language isn't the compiler. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-31 01:27 +0000 |
| Message-ID | <slrniu8gg4.rv2.usenet-nospam@guild.seebs.net> |
| In reply to | #5068 |
On 2011-05-31, Rui Maciel <rui.maciel@gmail.com> wrote: > Conversely, if we have a compiler which bijectively maps C code to object > code and if a programmer writes C code with that particular compiler in > mind then he is able to know exactly what assembly code will be generated > from his code. And yet, the language never ceassed to be C. I think the difference is that the C program's meaning can be understood without any reference to the targeted processor. > As I've demonstrated above, it can be the case for the author of an C > program and it may not be the case for the author of an assembly program. Doesn't matter what a specific author knows; what matters is what the code specifies. The C program is still the same program fed to a different compiler for a different architecture. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-31 10:37 -0700 |
| Message-ID | <lnwrh6py93.fsf@nuthaus.mib.org> |
| In reply to | #5068 |
Rui Maciel <rui.maciel@gmail.com> writes:
> Michael Press wrote:
>> The author of a program for a macro assembler
>> knows exactly what machine instructions will be
>> produced from his program.
>
> If he uses macros, either pre-defined ones or macros which he didn't
> write, then he doesn't know what machine instructions will be produced by
> his program.
But he can find out easily enough.
If I'm writing an assembly program, I don't need to know the op code for
the MOV instruction. If I do happen to know it, that doesn't mean I'm
now writing machine code; I'm still writing assembly code.
> If he compiles his assembly code with a compiler which
> performs any form of code optimization then he doesn't know what machine
> instructions will be produced by his program. And yet, the language never
> ceassed to be assembly.
The input language ceased to be assembly when it stopped specifying
CPU instructions.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web