Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56536 > unrolled thread
| Started by | krishna.myneni@ccreweb.org |
|---|---|
| First post | 2017-04-01 06:36 -0700 |
| Last post | 2017-04-06 10:53 -0700 |
| Articles | 20 on this page of 127 — 22 participants |
Back to article view | Back to comp.lang.forth
LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 06:36 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-01 14:57 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:55 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 15:24 +0000
Re: LLVM and Forth rickman <gnuarm@gmail.com> - 2017-04-01 11:21 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:57 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-02 04:02 -0500
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-02 06:35 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 14:41 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 01:09 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:32 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 13:52 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 07:59 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 16:08 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 12:22 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-03 20:10 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 22:19 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:12 +0200
Re: LLVM and Forth Walter Banks <walter@bytecraft.com> - 2017-04-05 17:27 -0400
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 14:29 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 03:17 -0500
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 05:04 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 12:55 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 10:08 -0500
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 17:05 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-04 11:29 -0500
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 19:11 +0200
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-04 21:29 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-05 15:01 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-05 18:42 +0100
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:01 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 18:48 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 18:42 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-07 04:02 -0500
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 21:18 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:43 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 20:54 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:53 +0000
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 00:38 +0000
Re: LLVM and Forth James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:46 -0400
Re: LLVM and Forth Robert Wessel <robertwessel2@yahoo.com> - 2017-04-09 22:27 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 12:36 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 14:09 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 13:07 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 16:18 +0100
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-10 11:51 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 21:32 +0000
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-12 18:29 -0400
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-12 15:29 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-13 02:55 +0200
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-10 18:38 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 11:54 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-10 10:17 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:02 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 10:03 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 03:25 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 11:24 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 04:55 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 12:28 +0000
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:16 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 15:38 +0200
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:06 +0200
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 17:57 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-05 00:44 -0400
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 00:00 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 08:47 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-05 11:04 -0500
Re: LLVM and Forth john <anon@example.com> - 2017-04-05 18:04 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-05 13:04 -0700
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-05 18:20 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:14 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 12:33 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:49 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 18:55 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 20:41 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:47 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:56 +0100
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 23:59 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 17:10 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-07 03:33 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:48 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 15:06 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 22:45 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:27 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-09 21:26 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 13:35 -0400
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-09 14:07 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 12:16 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:27 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:24 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 03:26 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-06 04:05 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 06:50 -0500
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:23 -0400
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:44 -0500
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 10:57 +0100
Re: LLVM and Forth peter.m.falth@gmail.com - 2017-04-05 05:29 -0700
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-14 02:04 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:03 +0200
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 00:44 +0000
Re: LLVM and Forth alex@rivadpm.com - 2017-04-16 05:53 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 15:43 +0000
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 22:27 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-18 02:45 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-18 18:26 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 19:51 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 19:08 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:42 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:29 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:48 +0100
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 11:49 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-03 20:39 -0400
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-02 21:15 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-02 15:18 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 13:07 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 09:45 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 22:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 15:25 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:35 +0100
Re: LLVM and Forth antispam@math.uni.wroc.pl - 2017-04-06 01:36 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 22:00 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-06 20:15 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:20 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:11 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 17:43 +0100
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:53 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | alex@rivadpm.com |
|---|---|
| Date | 2017-04-16 05:53 -0700 |
| Message-ID | <d6db3b6c-9e55-4434-aa42-f76a9d467f68@googlegroups.com> |
| In reply to | #57366 |
Excuse the dreadful cut and paste here --------- And then there is "add immediate" and a slew of load effective address tricks. These are all INC operations, only one(!) of the INC *instructions* is missing. You may never notice that the INC Rod refers too is missing, because an assembler may substitute one of the alternatives with the same effect, without telling. -------- That is not correct. The INC instruction does not set the same flags as ADD and they are not substitutable for each other, and no sane assembler will do so. Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-16 15:43 +0000 |
| Message-ID | <2017Apr16.174347@mips.complang.tuwien.ac.at> |
| In reply to | #57438 |
alex@rivadpm.com writes:
>The INC instruction does not set the same flags as ADD and they are not substitutable for each other, and no sane assembler will do so.
What actually happens is that the assembler chooses the 2-byte
encoding for the instruction, now that the 1-byte encoding is not
available:
Encoding Disassembly
ff c0 inc %eax
03 04 25 01 00 00 00 add 0x1,%eax
67 8d 40 01 lea 0x1(%eax),%eax
BTW, please limit the line length to about 70 characters.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-04-16 22:27 +0000 |
| Message-ID | <xn0kotncl42j8v4002@nntp.aioe.org> |
| In reply to | #57448 |
Anton Ertl wrote: > alex@rivadpm.com writes: > > The INC instruction does not set the same flags as ADD and they are > > not substitutable for each other, and no sane assembler will do so. > > What actually happens is that the assembler chooses the 2-byte > encoding for the instruction, now that the 1-byte encoding is not > available: Sure, but the fact remains that the INC instruction is still available in x86-64, even if it has a different encoding. And he is right, INC does not modify the carry flag (which, BTW caused a partial flag stall in combination with ADC in some of my BigInteger code, making it terribly slow on some of my older computers) while "ADD reg,1" does. Then there is "LEA reg,[reg+1]", but that doesn't set some other flags that might be required (like, e.g. when counting down -- instead of DEC -- the zero flag). Oh, it is sometimes a mess. -- Rudy Velthuis http://www.rvelthuis.de "A single death is a tragedy, a million deaths is a statistic." -- Joseph Stalin.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-18 02:45 +0200 |
| Message-ID | <od3nk1$fkr$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57438 |
In article <d6db3b6c-9e55-4434-aa42-f76a9d467f68@googlegroups.com>, <alex@rivadpm.com> wrote: > >Excuse the dreadful cut and paste here > > >--------- >And then there is "add immediate" and a slew of >load effective address tricks. These are all INC operations, >only one(!) of the INC *instructions* is missing. > >You may never notice that the INC Rod refers too is missing, >because an assembler may substitute one of the alternatives >with the same effect, without telling. > >-------- > >That is not correct. The INC instruction does not set the same flags >as ADD and they are not substitutable for each other, and no sane >assembler will do so. A programmer may choose to use LEA instead of INC taking into account the flags. E.g. it may influence the speed because arithmetic and addressing parts of the processor are concurrent. There are several instructions that in my ciasdis they are named INC, and INC|X, INC|X, AX| INC, X| R| AX| have exactly the same effect on flags. That is what I meant. This is not uncommon with Intel. I cite from the assembler chapter of ciforth: Compare the opcode sheets with Intel's to get an overview of what I have done to the instruction set. In essence I have re-engineered it to make it reverse assemblable, i.e. from a disassembly you can regenerate the machine code. This is not true for Intel's instruction set, e.g. Intel has the same opcode for `MOV, X| T| AX'| R| BX| ' and `MOV, X| F| BX'| R| AX|'. Not everybody seems to know how poor the x86 design is. > >Alex -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-18 18:26 +0100 |
| Message-ID | <od5i1v$b1k$2@dont-email.me> |
| In reply to | #57514 |
On 4/18/2017 01:45, Albert van der Horst wrote: > Compare the opcode sheets with Intel's to get an overview of what I > have done to the instruction set. In essence I have re-engineered it to > make it reverse assemblable, i.e. from a disassembly you can regenerate > the machine code. This is not true for Intel's instruction set, e.g. > Intel has the same opcode for `MOV, X| T| AX'| R| BX| ' and `MOV, > X| F| BX'| R| AX|'. What are those in Intel syntax? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-20 19:51 +0200 |
| Message-ID | <odasev$844$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57560 |
In article <od5i1v$b1k$2@dont-email.me>, Alex <alex@rivadpm.com> wrote:
>On 4/18/2017 01:45, Albert van der Horst wrote:
>> Compare the opcode sheets with Intel's to get an overview of what I
>> have done to the instruction set. In essence I have re-engineered it to
>> make it reverse assemblable, i.e. from a disassembly you can regenerate
>> the machine code. This is not true for Intel's instruction set, e.g.
>> Intel has the same opcode for `MOV, X| T| AX'| R| BX| ' and `MOV,
>> X| F| BX'| R| AX|'.
>
>What are those in Intel syntax?
MOV %BX,%AX ; In normal intel syntax.
MOV AX, BX ; In intel intel syntax.
That is not important. They are the same ! Any assembler except ciasdis
just picks one.
>
>--
>Alex
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-20 19:08 +0100 |
| Message-ID | <odat9u$eob$1@dont-email.me> |
| In reply to | #57653 |
On 4/20/2017 18:51, Albert van der Horst wrote: > In article <od5i1v$b1k$2@dont-email.me>, Alex <alex@rivadpm.com> wrote: >> On 4/18/2017 01:45, Albert van der Horst wrote: >>> Compare the opcode sheets with Intel's to get an overview of what I >>> have done to the instruction set. In essence I have re-engineered it to >>> make it reverse assemblable, i.e. from a disassembly you can regenerate >>> the machine code. This is not true for Intel's instruction set, e.g. >>> Intel has the same opcode for `MOV, X| T| AX'| R| BX| ' and `MOV, >>> X| F| BX'| R| AX|'. >> >> What are those in Intel syntax? > > MOV %BX,%AX ; In normal intel syntax. > MOV AX, BX ; In intel intel syntax. > > That is not important. They are the same ! Any assembler except ciasdis > just picks one. > I presume you're meaning GAS vs Intel syntax, because see showit code showit ( ? -- ? ) \ showit is defined in (console) \ call compiled \ code=$41BECC len=6 type=129 ( $0 ) mov ax bx \ 668BC3 ( $3 ) mov bx ax \ 668BD8 ( $6 ) ret \ C3 ( end ) ok In my assembler, the destination is the first operand; the source is the second. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-20 20:42 +0200 |
| Message-ID | <odavfd$8o7$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57654 |
In article <odat9u$eob$1@dont-email.me>, Alex <alex@rivadpm.com> wrote:
>On 4/20/2017 18:51, Albert van der Horst wrote:
>> In article <od5i1v$b1k$2@dont-email.me>, Alex <alex@rivadpm.com> wrote:
>>> On 4/18/2017 01:45, Albert van der Horst wrote:
>>>> Compare the opcode sheets with Intel's to get an overview of what I
>>>> have done to the instruction set. In essence I have re-engineered it to
>>>> make it reverse assemblable, i.e. from a disassembly you can regenerate
>>>> the machine code. This is not true for Intel's instruction set, e.g.
>>>> Intel has the same opcode for `MOV, X| T| AX'| R| BX| ' and `MOV,
>>>> X| F| BX'| R| AX|'.
>>>
>>> What are those in Intel syntax?
>>
>> MOV %BX,%AX ; In normal intel syntax.
>> MOV AX, BX ; In intel intel syntax.
>>
>> That is not important. They are the same ! Any assembler except ciasdis
>> just picks one.
>>
>
>I presume you're meaning GAS vs Intel syntax, because
>
>see showit
>code showit ( ? -- ? )
>\ showit is defined in (console)
>\ call compiled
>\ code=$41BECC len=6 type=129
>( $0 ) mov ax bx \ 668BC3
>( $3 ) mov bx ax \ 668BD8
>( $6 ) ret \ C3 ( end ) ok
Why do you draw instructions with a different effect into it?
>
>In my assembler, the destination is the first operand; the source is the
>second.
So for your assembler we are talking about
MOV BX,AX ; In intel intel syntax.
Why even mention
>( $0 ) mov ax bx \ 668BC3
It has nothing to do with what we are discussing here?
Or did I make it too confusing?
I hope it is clear that
Move a cell to primary register ax from register bx
and
move a cell from primary register bx to register ax
has the same effect, but two different opcodes:
---------
WANT ASSEMBLERi86
HERE
OK
MOV, X| F| BX'| R| AX|
OK
MOV, X| T| AX'| R| BX|
OK
20 DUMP
0805,9980: 89D8 8BC3 0000 0000 0000 0000 0000 0000 |................|
0805,9990: 0000 0000 0000 0000 0000 0000 0000 0000 |................|
(32 bits not 64). (The 66's in Alex's code means he is on 64 bits).
Apparently you have choosen the second one.
It is interesting whether the first one is disassembled in your system
correctly, because it is a correct opcode that you don't generate
yourself, ever.
66 89 D8
It should be
( .. ) mov bx ax \ 6689D8
>
>--
>Alex
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-20 20:29 +0100 |
| Message-ID | <odb21j$vnm$1@dont-email.me> |
| In reply to | #57658 |
On 4/20/2017 19:42, Albert van der Horst wrote: > In article <odat9u$eob$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >> On 4/20/2017 18:51, Albert van der Horst wrote: >>> In article <od5i1v$b1k$2@dont-email.me>, Alex <alex@rivadpm.com> wrote: >>>> On 4/18/2017 01:45, Albert van der Horst wrote: >>>>> Compare the opcode sheets with Intel's to get an overview of what I >>>>> have done to the instruction set. In essence I have re-engineered it to >>>>> make it reverse assemblable, i.e. from a disassembly you can regenerate >>>>> the machine code. This is not true for Intel's instruction set, e.g. >>>>> Intel has the same opcode for `MOV, X| T| AX'| R| BX| ' and `MOV, >>>>> X| F| BX'| R| AX|'. >>>> >>>> What are those in Intel syntax? >>> >>> MOV %BX,%AX ; In normal intel syntax. >>> MOV AX, BX ; In intel intel syntax. >>> >>> That is not important. They are the same ! Any assembler except ciasdis >>> just picks one. >>> >> >> I presume you're meaning GAS vs Intel syntax, because >> >> see showit >> code showit ( ? -- ? ) >> \ showit is defined in (console) >> \ call compiled >> \ code=$41BECC len=6 type=129 >> ( $0 ) mov ax bx \ 668BC3 >> ( $3 ) mov bx ax \ 668BD8 >> ( $6 ) ret \ C3 ( end ) ok > Why do you draw instructions with a different effect into it? > > >> >> In my assembler, the destination is the first operand; the source is the >> second. > > So for your assembler we are talking about > MOV BX,AX ; In intel intel syntax. > > Why even mention >> ( $0 ) mov ax bx \ 668BC3 > It has nothing to do with what we are discussing here? > Or did I make it too confusing? Yes. > > I hope it is clear that > Move a cell to primary register ax from register bx > and > move a cell from primary register bx to register ax > has the same effect, but two different opcodes: > --------- > WANT ASSEMBLERi86 > HERE > OK > MOV, X| F| BX'| R| AX| > OK > MOV, X| T| AX'| R| BX| > OK > 20 DUMP > > 0805,9980: 89D8 8BC3 0000 0000 0000 0000 0000 0000 |................| > 0805,9990: 0000 0000 0000 0000 0000 0000 0000 0000 |................| > > (32 bits not 64). (The 66's in Alex's code means he is on 64 bits). No, the 66 is 16 bit mode. mode64/32 ok code show2 ok mov ax bx ok mov eax ebx ok mov rax rbx ok next; ok see show2 code show2 ( ? -- ? ) \ show2 is defined in (console) \ call compiled \ code=$41BEE9 len=8 type=129 ( $0 ) mov ax bx \ 668BC3 ( $3 ) mov eax ebx \ 8BC3 ( $5 ) mov rax rbx \ 488BC3 ( $8 ) ret \ C3 ( end ) ok > > Apparently you have choosen the second one. > > It is interesting whether the first one is disassembled in your system > correctly, because it is a correct opcode that you don't generate > yourself, ever. > > 66 89 D8 > > It should be > ( .. ) mov bx ax \ 6689D8 > code-here 66 code-b, 89 code-b, d8 code-b, dis ( $41BEE1 ' show64 $9 + ) ( $0 ) mov ax bx \ 6689D8 -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-20 20:48 +0100 |
| Message-ID | <odb346$46p$1@dont-email.me> |
| In reply to | #57663 |
On 4/20/2017 20:29, Alex wrote: >> >> Apparently you have choosen the second one. >> >> It is interesting whether the first one is disassembled in your system >> correctly, because it is a correct opcode that you don't generate >> yourself, ever. >> >> 66 89 D8 >> >> It should be >> ( .. ) mov bx ax \ 6689D8 >> > > code-here 66 code-b, 89 code-b, d8 code-b, dis > ( $41BEE1 ' show64 $9 + ) > ( $0 ) mov ax bx \ 6689D8 > There are two encodings for mov reg1 reg2. The direction bit determines which register is which. In octal and ignoring the prefix byte; 210+dw xrm MOV r/m, reg The direction bit is +002, the w bit is +001 (0 indicates 8 bit registers). So the opcode for reg1,reg2 is 211 octal, or $89; for reg2,reg1 is 213 octal or $8B. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-04-21 11:49 +0000 |
| Message-ID | <xn0kozuox8jdemq008@nntp.aioe.org> |
| In reply to | #57653 |
Albert van der Horst wrote: > MOV %BX,%AX ; In normal intel syntax. Did you mean AT&T synatx? That is not normal Intel syntax. It is IMO, an abomination. > MOV AX, BX ; In intel intel syntax. That is normal Intel syntax. -- Rudy Velthuis http://www.rvelthuis.de "Experience is a hard teacher because she gives the test first, the lesson afterwards." --Vernon Saunders Law
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-03 20:39 -0400 |
| Message-ID | <20170403203945.034012ea@_> |
| In reply to | #56586 |
On Sun, 2 Apr 2017 06:35:25 -0700 (PDT)
krishna.myneni@ccreweb.org wrote:
> On Sunday, April 2, 2017 at 4:02:26 AM UTC-5, Andrew Haley wrote:
> > krishna.myneni@ccreweb.org wrote:
> If one were to write a Forth to C translator, how likely is it that
> the translator would result in C code which is considered undefined
> in the new C standard,
IMO, unlikely, especially if the Forth was mostly written in high-level
Forth, being built up from "primitives" like eForth. However, it is
entirely possible that there are complicated interactions.
Typically, eForths have 30 to 60 or so low-level words or
"primitives". All the high-level words are coded in terms of the
primitives. The advantage here is that the high-level words translate
easily to C, and most of an eForth like Forth is coded as high-level
Forth words. So, much of your work is done for you. You just need to
implement the "primitives" in C and the Forth data structures, like
stacks, etc.
In this scenario, high-level Forth words would become a procedure call,
where each procedure has a list of calls to other procedures. Forth
"primitive" words would be C procedures that actually do some work on
the stacks, instead of just calling other procedures. I think the only
issue here would be conversion of the names for Forth words, e.g., '+'
'\' etc, to procedure names which are valid in C, e.g., 'add' 'divide'
etc.
E.g., a high-level Forth word using a "primitive" twice:
: DUP2 DUP DUP ;
In C,
void DUP2(void) /* high-level Forth word */
{
DUP(); /* list of procedures */
DUP();
}
void DUP(void) /* "primitive" Forth word */
{ /* actual code to modify Forth stacks */
TOS=*SP; /* retrieve TOS value */
SP++; /* adjust stack pointer to add space for new TOS */
*SP=TOS; /* save TOS value into new TOS */
}
As you can see, the high-level definition of DUP2 can be converted to C
simply by inserting or replacing text. E.g., ':' becomes 'void', ';'
becomes '}', the definition name has '(void) {' inserted after it, and
the called Forth words have '();' inserted afterwards.
The "primitive" DUP actually needs C code to do work on the Forth
stacks. The functions have no parameters in C because the code uses a
data stack set up in C for Forth, and not C's internal stack.
Of course, the code would need to be self-contained to be a compiled
program, otherwise, it's just a library of functions. I.e., you'd need
to have all interactive commands saved as text to be compiled. E.g.,
you'd not only need the code for DUP2 but also the interactive line
using DUP2 such as:
: DUP2 DUP DUP ;
5 DUP2 . . .
So, the "5 DUP2 . . ." would become your main() procedure in C:
int main(void)
{
LIT(5);
DUP2();
DOT();
DOT();
DOT();
}
As you can see '.' is an example of the name conversion issue, i.e.,
'.' in Forth to DOT() in C. Implementing DOT() is left as an exercise
for the reader.
Also, all control-flow words in Forth, e.g., IF ELSE THEN DO LOOP BEGIN
AGAIN UNTIL WHILE REPEAT etc, will map directly onto existing C
control-flow constructs. So, converting Forth control-flow to C is not
a problem either.
One issue is that the Forth interactive commands and Forth definitions
can occur in any order, so your conversion program must filter out the
Forth definitions and define them first. This is an issue if Forth
words are redefined. The control-flow of the Forth program will be
changed by re-ordering to fit C's requirements, and C will complain
about redefining a procedure. I.e., your conversion program will need
to keep track of both DUP2's below and need to treat each of them as
being distinct procedures:
: DUP2 DUP DUP ;
5 DUP2 . . .
: DUP2 DUP DUP + ;
6 DUP2 . .
void DUP2_1(void) /* high-level Forth word */
{
DUP(); /* list of procedures */
DUP();
}
void DUP2_2(void) /* high-level Forth word */
{
DUP(); /* list of procedures */
DUP();
PLUS();
}
void DUP(void) /* "primitive" Forth word */
{ /* actual code to modify Forth stacks */
TOS=*SP; /* retrieve TOS value */
SP++; /* adjust stack pointer to add space for new TOS */
*SP=TOS; /* save TOS value into new TOS */
}
void PLUS(void)
{
TOS=*SP
SP--;
*SP+=TOS;
}
int main(void)
{
LIT(5);
DUP2_1();
DOT();
DOT();
DOT();
LIT(6);
DUP2_2();
DOT();
DOT();
}
As you can see, both DUP2's are defined first, kept distinct, and then
the respective interactive commands for each DUP2 are called in main(),
thereby preserving the correct control-flow of the program. Obviously,
this will require that you implement a Forth dictionary as a look-up
table to determine the correct DUP2 to use during the conversion ...
I.e., when "6 DUP2" is seen, the look-up will need to correctly return
DUP2_2() for DUP2 instead of DUP2_1(). Depending on how you convert
code for string words, you may also need to filter out strings and
define them first too.
To prevent naming collisions in C, it may make sense to convert all
Forth procedure names to numbers and emit a comment as to what the
original name was. The 'X' is because C requires a first character of a
procedure name to be alphabet character or an underscore. A counter
would be incremented upon each new colon-def in Forth in order to
generate the numeric names.
void X0002(void) /* DUP */
{
...
}
void X0003(void) /* DUP */
{
...
}
int main(void)
{
X0001(5); /* LIT */
X0002(); /* DUP */
...
X0001(6); /* LIT */
X0003(); /* DUP */
...
}
> i.e. how problematic would "nasal demons" be
> in the translated code?
AISI, one operation in Forth which might be an issue is the
CREATE ... DOES> construct. It's somewhat object-oriented. I haven't
attempted DOES> to convert DOES> code either by myself or by program
conversions. However, I suspect the conversion is rather straight
forward, as DOES> basically redirects the list of procedures which are
called to another set.
Another area of problems might be words with different run-time versus
compile-time actions, etc. The word DUP2 in the example obviously
works the same way for both, as will most "primitives". So, I suspect
much of the compile-time actions will be taken care of by the code
conversion to C. The resulting C code obviously should be the run-time
actions for the Forth code, with compile-time actions taken care of in
the code.
I hope that helps. I'm sure that's a rather rudimentary presentation,
but you'll discover and solve other issues as you work on the problem.
So, I'd guess that solving those basic issues above, and implementing
the "primitives" will solve most of the conversion problems, especially
if the high-level words are constructed using "primitives" like eForth.
Rod Pemberton
--
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-02 21:15 +0100 |
| Message-ID | <obrlv4$u1m$1@dont-email.me> |
| In reply to | #56536 |
On 4/1/2017 14:36, krishna.myneni@ccreweb.org wrote: > Question: > > Are there any existing Forth systems built from the LLVM tools (link > below)? What advantages might LLVM provide for a low-level language > such as Forth? > > Krishna > > http://llvm.org/ > Early in the development of LLVM there was this; Stacker. It was very Forth like, but compiled and no interpretation. http://web.cs.ucla.edu/classes/spring08/cs259/llvm-2.2/docs/Stacker.html It appears to have not been maintained, and I don't know where the source is.. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-02 15:18 -0700 |
| Message-ID | <798e62ed-1ab9-45f8-9487-3d320888bbcd@googlegroups.com> |
| In reply to | #56600 |
On Sunday, April 2, 2017 at 1:15:22 PM UTC-7, Alex wrote: > On 4/1/2017 14:36, krishna.myneni@ccreweb.org wrote: > > Question: > > > > Are there any existing Forth systems built from the LLVM tools (link > > below)? What advantages might LLVM provide for a low-level language > > such as Forth? > > > > Krishna > > > > http://llvm.org/ > > > > Early in the development of LLVM there was this; Stacker. It was very > Forth like, but compiled and no interpretation. > > http://web.cs.ucla.edu/classes/spring08/cs259/llvm-2.2/docs/Stacker.html This is primarily why I'm not interested in LLVM --- because it has to be cross-compiled into --- you can't have the traditional interactive Forth development system.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-03 13:07 +0100 |
| Message-ID | <obtdo0$74p$1@dont-email.me> |
| In reply to | #56604 |
On 4/2/2017 23:18, hughaguilar96@gmail.com wrote: > On Sunday, April 2, 2017 at 1:15:22 PM UTC-7, Alex wrote: >> On 4/1/2017 14:36, krishna.myneni@ccreweb.org wrote: >>> Question: >>> >>> Are there any existing Forth systems built from the LLVM tools >>> (link below)? What advantages might LLVM provide for a low-level >>> language such as Forth? >>> >>> Krishna >>> >>> http://llvm.org/ >>> >> >> Early in the development of LLVM there was this; Stacker. It was >> very Forth like, but compiled and no interpretation. >> >> http://web.cs.ucla.edu/classes/spring08/cs259/llvm-2.2/docs/Stacker.html > >> > This is primarily why I'm not interested in LLVM --- because it has > to be cross-compiled into --- you can't have the traditional > interactive Forth development system. > Cross compiled? What? Gforth demonstrates it's more than possible to write an interactive Forth in a high level language. Stacker demonstrates that it's possible to use LLVM to generate code from a Forth like language. So what technical reason is there that you can't you have interactive Forth development system that uses LLVM as its code generator? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-03 09:45 -0700 |
| Message-ID | <e4d3253b-d3ae-4b07-9172-2914c5a8e5e8@googlegroups.com> |
| In reply to | #56654 |
On Monday, April 3, 2017 at 5:07:19 AM UTC-7, Alex wrote: > On 4/2/2017 23:18, hughaguilar96@gmail.com wrote: > > On Sunday, April 2, 2017 at 1:15:22 PM UTC-7, Alex wrote: > >> On 4/1/2017 14:36, krishna.myneni@ccreweb.org wrote: > >>> Question: > >>> > >>> Are there any existing Forth systems built from the LLVM tools > >>> (link below)? What advantages might LLVM provide for a low-level > >>> language such as Forth? > >>> > >>> Krishna > >>> > >>> http://llvm.org/ > >>> > >> > >> Early in the development of LLVM there was this; Stacker. It was > >> very Forth like, but compiled and no interpretation. > >> > >> http://web.cs.ucla.edu/classes/spring08/cs259/llvm-2.2/docs/Stacker.html > > > >> > > This is primarily why I'm not interested in LLVM --- because it has > > to be cross-compiled into --- you can't have the traditional > > interactive Forth development system. > > > > Cross compiled? What? > > Gforth demonstrates it's more than possible to write an interactive > Forth in a high level language. Stacker demonstrates that it's possible > to use LLVM to generate code from a Forth like language. So what > technical reason is there that you can't you have interactive Forth > development system that uses LLVM as its code generator? Performance. It is possible to write a traditional Forth in any language --- John Passaniti's claim to fame was to have written a "Forth-like interpreter" in Perl (afaik, Perl was the only programming language he knew, as all of his code posted on comp.lang.forth was in Perl) --- this doesn't mean that it is a good idea. With something like LLVM, I would write a cross-compiler and generate LLVM code --- like STC except that it would be LLVM assembly-language --- that is the only way to get any performance, but the downside is there is no interactive Forth system. I wouldn't actually use LLVM anyway --- it isn't designed for Forth --- any Forth programmer could design a VM that is for Forth (has the Forth stacks).
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-03 22:52 +0100 |
| Message-ID | <obug0u$7j2$1@dont-email.me> |
| In reply to | #56668 |
On 4/3/2017 17:45, hughaguilar96@gmail.com wrote: > On Monday, April 3, 2017 at 5:07:19 AM UTC-7, Alex wrote: >> On 4/2/2017 23:18, hughaguilar96@gmail.com wrote: >>> On Sunday, April 2, 2017 at 1:15:22 PM UTC-7, Alex wrote: >>>> On 4/1/2017 14:36, krishna.myneni@ccreweb.org wrote: >>>>> Question: >>>>> >>>>> Are there any existing Forth systems built from the LLVM >>>>> tools (link below)? What advantages might LLVM provide for a >>>>> low-level language such as Forth? >>>>> >>>>> Krishna >>>>> >>>>> http://llvm.org/ >>>>> >>>> >>>> Early in the development of LLVM there was this; Stacker. It >>>> was very Forth like, but compiled and no interpretation. >>>> >>>> http://web.cs.ucla.edu/classes/spring08/cs259/llvm-2.2/docs/Stacker.html >>> >>>> >>> >>>> >>>> >>> This is primarily why I'm not interested in LLVM --- because it has >>> to be cross-compiled into --- you can't have the traditional >>> interactive Forth development system. >>> >> >> Cross compiled? What? >> >> Gforth demonstrates it's more than possible to write an >> interactive Forth in a high level language. Stacker demonstrates >> that it's possible to use LLVM to generate code from a Forth like >> language. So what technical reason is there that you can't you >> have interactive Forth development system that uses LLVM as its >> code generator? > > Performance. So you think that most of the time in Forth is spent compiling? > > It is possible to write a traditional Forth in any language --- John > Passaniti's claim to fame was to have written a "Forth-like > interpreter" in Perl (afaik, Perl was the only programming language > he knew, as all of his code posted on comp.lang.forth was in Perl) > --- this doesn't mean that it is a good idea. > > With something like LLVM, I would write a cross-compiler and > generate LLVM code --- like STC except that it would be LLVM > assembly-language --- that is the only way to get any performance, > but the downside is there is no interactive Forth system. Again, why write a "cross compiler"? Why would it not be possible to have an interactive Forth system? > > I wouldn't actually use LLVM anyway --- it isn't designed for Forth > --- any Forth programmer could design a VM that is for Forth (has > the Forth stacks). > Probably just as well. Do you actually know what LLVM is? In the LLVM case, the clue is not in the name. It's not a VM. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-04-03 15:25 -0700 |
| Message-ID | <b9529528-ee1d-4b17-af0d-b4cb177f338b@googlegroups.com> |
| In reply to | #56675 |
On Monday, April 3, 2017 at 2:52:20 PM UTC-7, Alex wrote: > On 4/3/2017 17:45, hughaguilar96@gmail.com wrote: > > Performance. > > So you think that most of the time in Forth is spent compiling? run-time performance
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-06 09:35 +0100 |
| Message-ID | <oc4uen$jt8$1@dont-email.me> |
| In reply to | #56676 |
On 4/3/2017 23:25, hughaguilar96@gmail.com wrote: > On Monday, April 3, 2017 at 2:52:20 PM UTC-7, Alex wrote: >> On 4/3/2017 17:45, hughaguilar96@gmail.com wrote: >>> Performance. >> >> So you think that most of the time in Forth is spent compiling? > > run-time performance > I just saw this. Clueless. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-04-06 01:36 +0000 |
| Message-ID | <oc463g$m8k$1@z-news.wcss.wroc.pl> |
| In reply to | #56604 |
hughaguilar96@gmail.com wrote:
> On Sunday, April 2, 2017 at 1:15:22 PM UTC-7, Alex wrote:
> >
> > Early in the development of LLVM there was this; Stacker. It was very
> > Forth like, but compiled and no interpretation.
> >
> > http://web.cs.ucla.edu/classes/spring08/cs259/llvm-2.2/docs/Stacker.html
>
> This is primarily why I'm not interested in LLVM --- because it has to be cross-compiled into --- you can't have the traditional interactive Forth development system.
Apparently you do not understand how LLVM works. You can use LLVM
as a traditional compiler. But you can also use it for run-time
code generation. Basically, you type some input to your Forth,
your Forth translates it and calls LLVM to generate code. LLVM
puts machine code in a buffer and you can immediately call this
code. In other words once you pressed Enter you see results
of running your code -- as interactive as it can be.
Several big name products that used to contains their own
interpreters now use LLVM to get faster code for interactive
use.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web