Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #18643 > unrolled thread

Examples of current implementations in Forth for bachelor thesis

Back to article view | Back to comp.lang.forth

Contents

  Examples of current implementations in Forth for bachelor thesis Oliver Bach <decfreak@googlemail.com> - 2013-01-10 17:28 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-10 19:52 -0800
    Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-11 03:35 -0500
      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-14 15:13 -0800
        Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-14 21:16 -0500
          Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-15 14:47 -0800
            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-18 23:24 -0500
    Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-11 04:08 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Spam@ControlQ.com - 2013-01-11 13:09 -0500
      Re: Examples of current implementations in Forth for bachelor thesis Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-01-12 11:59 +0100
    Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-13 07:41 +1300
      Re: Examples of current implementations in Forth for bachelor thesis Chris <xrissmith@me.com> - 2013-01-12 21:05 -0800
        Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-13 22:26 +1300
    Re: Examples of current implementations in Forth for bachelor thesis gavino_himself <visploveslisp@gmail.com> - 2013-01-13 18:41 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-17 23:42 -0800
      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-19 18:21 -0800
        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-20 14:26 +0100
          Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-20 10:58 -0600
          Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-20 15:46 -0800
            Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 01:51 -0800
              Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-21 04:10 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 04:45 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 04:48 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-21 22:01 +0100
                    Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 13:42 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-22 02:18 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 01:06 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Lauri Alanko <la@iki.fi> - 2013-02-01 04:54 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 19:34 -1000
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-02 16:32 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-02 18:17 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-02 17:51 +0000
              Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-21 14:55 +0000
            Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 03:18 -0500
              Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 01:10 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 03:31 -0600
                  Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 03:41 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 14:36 -0500
                    Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 17:23 -0600
                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 09:38 -0500
                Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 12:52 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:31 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:35 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 18:22 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 09:40 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 21:02 +0100
                            Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 13:30 -0800
                              Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 23:07 +0100
                                Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 15:16 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-23 13:07 -0500
                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-25 08:33 +0100
                            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 16:46 -0500
                              Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-25 23:31 +0100
                                Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-26 18:09 -0500
                                  Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-27 10:15 +0100
                                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-31 14:41 -0500
                                      Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-31 21:03 +0100
                                        Re: Examples of current implementations in Forth for bachelor thesis mhx@iae.nl (Marcel Hendrix) - 2013-01-31 21:44 +0200
                                          Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-31 23:16 -0800
                                        Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-31 12:47 -0800
                                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-02-01 08:23 +0100
                    Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 04:48 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-22 17:30 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:32 -0800
                Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 14:35 -0500
                  Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 17:29 -0600
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-23 02:21 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 04:43 -0600
                      Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-23 03:28 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 09:19 -0600
                          Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-23 09:24 -0800
                            Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 12:01 -0600
                          Re: Examples of current implementations in Forth for bachelor thesis David Thompson <dave.thompson2@verizon.net> - 2013-02-04 03:09 -0500
                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 09:59 -0500
                      Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-26 03:05 -0600
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-26 04:38 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-26 07:19 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-26 13:13 -0600
                            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-26 17:00 -0500
                            Re: Examples of current implementations in Forth for bachelor thesis None <vandys@vsta.org> - 2013-01-26 22:04 +0000
              Re: Examples of current implementations in Forth for bachelor thesis kenney@cix.compulink.co.uk - 2013-01-22 18:20 -0600
                Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 23:25 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 03:02 -0600
              Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 18:28 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-25 16:57 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-25 08:41 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Coos Haak <chforth@hccnet.nl> - 2013-01-25 20:04 +0100
                      Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-26 09:25 +1300
                      Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-26 13:16 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-30 18:40 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-31 15:15 +0100
                      Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-31 15:55 +0000
                        Re: Examples of current implementations in Forth for bachelor thesis mhx@iae.nl (Marcel Hendrix) - 2013-02-24 00:57 +0200
                      Re: Examples of current implementations in Forth for bachelor thesis Brad Eckert <hwfwguy@gmail.com> - 2013-01-31 09:01 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-31 19:41 +0100
                          Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-01 16:08 +0000
                            Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-02 02:16 +0000
                              Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-02 16:38 +0100
                              Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-04 14:50 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 00:32 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-06 19:39 +0100

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#18957

On Jan 21, 9:51 am, Alex McDonald <b...@rivadpm.com> wrote:
> On Jan 20, 11:46 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
>
>
>
>
> > On Jan 20, 6:26 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>
> > > Hugh Aguilar wrote:
> > > > Aren't the terms VM and TIL synonymous? Every VM is a TIL.
>
> > > A threaded interpretative language means you have threaded code, i.e. a
> > > next is "goto *(ip)++" or something like that (indirect threaded means
> > > another indirection).  A VM can be byte-code, threaded code, or
> > > whatever, and may be implemented with a just in time compiler instead of
> > > a threaded code interpreter.
>
> > Over on the Racket mailing list, I asked what the point of a VM and
> > just-in-time compiling was, and why not just compile into machine-code
> > (do the hard work at compile-time rather than run-time). I was told
> > (by Stephen Bloch, the guru over there), that the use of a VM allows
> > an executable to run on various processors without being recompiled
> > --- so long as there is a VM for that processor. To do this however,
> > the xt values can't be absolute addresses (as done in Forth's DTC and
> > ITC). The xt values have to be relative offsets (as done in Forth's C-
> > based token threading, or Pascal's byte-code).
>
> Who told you that last part? It's nonsense. DTC and ITC can be
> relative offset based; Win32Forth v4 is exactly that.- Hide quoted text -
>
> - Show quoted text -

Hugh was referring to *xt's* when he mentioned absolute addresses.
Bear in mind that the person on the Racket mailing list would probably
not be aware that Forth code is normally distributed in source-code
form, so it's of little consequence to us in the Forth world just how
it is compiled.

Most other systems tend to distribute pre-compiled (object code)
files, so I can see how he would think that a VM that deals with
absolute addresses is a no-no. If distributing code in object code
form, then yes, it's not usuable, because there's no gurantee that
your VM is going to be in the same location as it was when it was
compiled (at least, not in a complex OS type environment).

[toc] | [prev] | [next] | [standalone]

#18959

On Jan 21, 12:10 pm, Mark Wills <forthfr...@gmail.com> wrote:
> On Jan 21, 9:51 am, Alex McDonald <b...@rivadpm.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 20, 11:46 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
> > > On Jan 20, 6:26 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>
> > > > Hugh Aguilar wrote:
> > > > > Aren't the terms VM and TIL synonymous? Every VM is a TIL.
>
> > > > A threaded interpretative language means you have threaded code, i.e. a
> > > > next is "goto *(ip)++" or something like that (indirect threaded means
> > > > another indirection).  A VM can be byte-code, threaded code, or
> > > > whatever, and may be implemented with a just in time compiler instead of
> > > > a threaded code interpreter.
>
> > > Over on the Racket mailing list, I asked what the point of a VM and
> > > just-in-time compiling was, and why not just compile into machine-code
> > > (do the hard work at compile-time rather than run-time). I was told
> > > (by Stephen Bloch, the guru over there), that the use of a VM allows
> > > an executable to run on various processors without being recompiled
> > > --- so long as there is a VM for that processor. To do this however,
> > > the xt values can't be absolute addresses (as done in Forth's DTC and
> > > ITC). The xt values have to be relative offsets (as done in Forth's C-
> > > based token threading, or Pascal's byte-code).
>
> > Who told you that last part? It's nonsense. DTC and ITC can be
> > relative offset based; Win32Forth v4 is exactly that.- Hide quoted text -
>
> > - Show quoted text -
>
> Hugh was referring to *xt's* when he mentioned absolute addresses.

Yes, I know that. They do not need to be absolute addresses.
Win32Forth v4 maintains them as relative addresses.

goto base+(*(ip)++)

> Bear in mind that the person on the Racket mailing list would probably
> not be aware that Forth code is normally distributed in source-code
> form, so it's of little consequence to us in the Forth world just how
> it is compiled.
>
> Most other systems tend to distribute pre-compiled (object code)
> files, so I can see how he would think that a VM that deals with
> absolute addresses is a no-no. If distributing code in object code
> form, then yes, it's not usuable, because there's no gurantee that
> your VM is going to be in the same location as it was when it was
> compiled (at least, not in a complex OS type environment).

It's call relocation. It can be done at run time as well as load time.

[toc] | [prev] | [next] | [standalone]

#18960

On Jan 21, 12:45 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Jan 21, 12:10 pm, Mark Wills <forthfr...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 21, 9:51 am, Alex McDonald <b...@rivadpm.com> wrote:
>
> > > On Jan 20, 11:46 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
> > > > On Jan 20, 6:26 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>
> > > > > Hugh Aguilar wrote:
> > > > > > Aren't the terms VM and TIL synonymous? Every VM is a TIL.
>
> > > > > A threaded interpretative language means you have threaded code, i.e. a
> > > > > next is "goto *(ip)++" or something like that (indirect threaded means
> > > > > another indirection).  A VM can be byte-code, threaded code, or
> > > > > whatever, and may be implemented with a just in time compiler instead of
> > > > > a threaded code interpreter.
>
> > > > Over on the Racket mailing list, I asked what the point of a VM and
> > > > just-in-time compiling was, and why not just compile into machine-code
> > > > (do the hard work at compile-time rather than run-time). I was told
> > > > (by Stephen Bloch, the guru over there), that the use of a VM allows
> > > > an executable to run on various processors without being recompiled
> > > > --- so long as there is a VM for that processor. To do this however,
> > > > the xt values can't be absolute addresses (as done in Forth's DTC and
> > > > ITC). The xt values have to be relative offsets (as done in Forth's C-
> > > > based token threading, or Pascal's byte-code).
>
> > > Who told you that last part? It's nonsense. DTC and ITC can be
> > > relative offset based; Win32Forth v4 is exactly that.- Hide quoted text -
>
> > > - Show quoted text -
>
> > Hugh was referring to *xt's* when he mentioned absolute addresses.
>
> Yes, I know that. They do not need to be absolute addresses.
> Win32Forth v4 maintains them as relative addresses.
>
> goto base+(*(ip)++)
>
> > Bear in mind that the person on the Racket mailing list would probably
> > not be aware that Forth code is normally distributed in source-code
> > form, so it's of little consequence to us in the Forth world just how
> > it is compiled.
>
> > Most other systems tend to distribute pre-compiled (object code)
> > files, so I can see how he would think that a VM that deals with
> > absolute addresses is a no-no. If distributing code in object code
> > form, then yes, it's not usuable, because there's no gurantee that
> > your VM is going to be in the same location as it was when it was
> > compiled (at least, not in a complex OS type environment).
>
> It's call relocation. It can be done at run time as well as load time.

s/call/called/

[toc] | [prev] | [next] | [standalone]

#18972

Alex McDonald wrote:
> It's call relocation. It can be done at run time as well as load time.

Yes, Win32Forth does it at run-time (which results in a lot of rel>abs 
and abs>rel for Windows calls), all other Forths I know of do it at load 
time, if they need to (e.g. Gforth, where the images are portable for 
architectures with same wordsize and endianess).

I'm not sure if this is really necessary today.  Private address spaces 
are now the norm, and OSes have their rules how to allocate memory for 
shared libraries, so when you specify an address in a region that's 
unlikely to used for that, you get the mmap() request.

This could be argued to go against address space layout randomization, a 
way to make attacks on typical C buffer overflows more difficult, so a 
Forth system using that technique won't benefit.  ASLR is helping a lot 
less than it was thought it should, because programmers figured out that 
you simply have to fill a large buffer with nops and put the malicous 
code at the end of it... at least on 32 bit processors, this works fine.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#18973

On Jan 21, 9:01 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Alex McDonald wrote:
> > It's call relocation. It can be done at run time as well as load time.
>
> Yes, Win32Forth does it at run-time (which results in a lot of rel>abs
> and abs>rel for Windows calls),

When I engineered the changes that became Win32Forth version 6, I made
the addresses absolute. REL>ABS and ABS>REL are noops in those
systems.

> all other Forths I know of do it at load
> time, if they need to (e.g. Gforth, where the images are portable for
> architectures with same wordsize and endianess).
>
> I'm not sure if this is really necessary today.  Private address spaces
> are now the norm, and OSes have their rules how to allocate memory for
> shared libraries, so when you specify an address in a region that's
> unlikely to used for that, you get the mmap() request.

Windows executables use relocation sections. They're not required for
the first load (for the EXE usually) since they are always loaded at
the fixed address $400000. DLLs (shared libraries) can theoretically
be loaded at any address, but the loader prefers to load at the
requested base address of the DLL if it's available, as then the
relocations can be avoided.

>
> This could be argued to go against address space layout randomization, a
> way to make attacks on typical C buffer overflows more difficult, so a
> Forth system using that technique won't benefit.  ASLR is helping a lot
> less than it was thought it should, because programmers figured out that
> you simply have to fill a large buffer with nops and put the malicous
> code at the end of it... at least on 32 bit processors, this works fine.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#18975

Alex McDonald wrote:

> On Jan 21, 9:01 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> Yes, Win32Forth does it at run-time (which results in a lot of
>> rel>abs and abs>rel for Windows calls),
> 
> When I engineered the changes that became Win32Forth version 6, I made
> the addresses absolute. REL>ABS and ABS>REL are noops in those
> systems.

Ok, so that stupid idea is now gone.  Good work.

> Windows executables use relocation sections. They're not required for
> the first load (for the EXE usually) since they are always loaded at
> the fixed address $400000. DLLs (shared libraries) can theoretically
> be loaded at any address, but the loader prefers to load at the
> requested base address of the DLL if it's available, as then the
> relocations can be avoided.

AFAIK, Windows supports ASLR nowadays (post Windows XP, i.e. starting 
with Windows Vista), which means that DLLs will usually *not* be loaded 
at their requested base address.  The main program will be loaded at 
$400000, since it's not compiled relocatible.

In any case: Gforth had load-time relocatible images right from start.  
The cross compiler needs taging, but the main image just gets loaded to 
two different addresses, and then we compare the two files.  The Gforth 
engine does not request a fixed address for the image, so we get the 
ASLR from the operating system.

However, even under Linux, the "EXE" itself is loaded at a fixed 
address, which kind-of defeats the purpose of an ASLR (that's because 
executables are not compiled with -fPIC).  Malware can still call some 
functions in the main program with known addresses.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#18990

On Jan 22, 1:18 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Alex McDonald wrote:
> > On Jan 21, 9:01 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> >> Yes, Win32Forth does it at run-time (which results in a lot of
> >> rel>abs and abs>rel for Windows calls),
>
> > When I engineered the changes that became Win32Forth version 6, I made
> > the addresses absolute. REL>ABS and ABS>REL are noops in those
> > systems.
>
> Ok, so that stupid idea is now gone.  Good work.
>
> > Windows executables use relocation sections. They're not required for
> > the first load (for the EXE usually) since they are always loaded at
> > the fixed address $400000. DLLs (shared libraries) can theoretically
> > be loaded at any address, but the loader prefers to load at the
> > requested base address of the DLL if it's available, as then the
> > relocations can be avoided.
>
> AFAIK, Windows supports ASLR nowadays (post Windows XP, i.e. starting
> with Windows Vista), which means that DLLs will usually *not* be loaded
> at their requested base address.  The main program will be loaded at
> $400000, since it's not compiled relocatible.

ASLR is an option on the EXE and DLLs (/DYNAMICBASE); and it's an all
of them have it from EXE down, or none of them are honoured. ASLR and
DEP (no execute in data segments) are only effective when used
together, according to the doc.

>
> In any case: Gforth had load-time relocatible images right from start.
> The cross compiler needs taging, but the main image just gets loaded to
> two different addresses, and then we compare the two files.  The Gforth
> engine does not request a fixed address for the image, so we get the
> ASLR from the operating system.

That's a mechanism I thought of adopting to build Forth DLLs. I
haven't needed to support a DLL yet, so... it never got done.

>
> However, even under Linux, the "EXE" itself is loaded at a fixed
> address, which kind-of defeats the purpose of an ASLR (that's because
> executables are not compiled with -fPIC).  Malware can still call some
> functions in the main program with known addresses.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#19339

In article <9309258.enKt5cl8Je@sunwukong.fritz.box>,
Bernd Paysan  <bernd.paysan@gmx.de> wrote:
> Alex McDonald wrote:
> > It's call relocation. It can be done at run time as well as load time.

> I'm not sure if this is really necessary today.  Private address spaces 
> are now the norm, and OSes have their rules how to allocate memory for 
> shared libraries, so when you specify an address in a region that's 
> unlikely to used for that, you get the mmap() request.

Well, there are still architectures without MMUs...

More pertinently, the reason for relocatability is interoperability.
Before the transition to ELF, shared libraries in Linux had fixed
addresses, so there had to be a globally centralized registry where
libraries were allocated a piece of address space to ensure that any
libraries could coexist in a single process. It was reportedly a pain.

If your Forth program (or whatever) had single-handed control over the
entire process, then sure, it could use fixed addresses. But modern
programs are often composed from multiple components implemented in
multiple languages, all linked together into a single address space in
a single process. The only way this can work is if everyone plays nice
and doesn't insist on getting a specific slice of the address space.


Lauri

[toc] | [prev] | [next] | [standalone]

#19340

On 1/31/13 6:54 PM, Lauri Alanko wrote:
> In article <9309258.enKt5cl8Je@sunwukong.fritz.box>,
> Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>> Alex McDonald wrote:
>>> It's call relocation. It can be done at run time as well as load time.
>
>> I'm not sure if this is really necessary today.  Private address spaces
>> are now the norm, and OSes have their rules how to allocate memory for
>> shared libraries, so when you specify an address in a region that's
>> unlikely to used for that, you get the mmap() request.
>
> Well, there are still architectures without MMUs...
>
> More pertinently, the reason for relocatability is interoperability.
> Before the transition to ELF, shared libraries in Linux had fixed
> addresses, so there had to be a globally centralized registry where
> libraries were allocated a piece of address space to ensure that any
> libraries could coexist in a single process. It was reportedly a pain.
>
> If your Forth program (or whatever) had single-handed control over the
> entire process, then sure, it could use fixed addresses. But modern
> programs are often composed from multiple components implemented in
> multiple languages, all linked together into a single address space in
> a single process. The only way this can work is if everyone plays nice
> and doesn't insist on getting a specific slice of the address space.

Since Forth was originally developed as a standalone system, it is more 
comfortable with fixed addresses, and does not normally generate 
linkable binaries. Versions that run under an OS that assign virtual 
address space, like Windows, can control space assigned by the system, 
and such implementations are also able to call library routines using 
system-wide protocols. Where it gets awkward is when we're running 
without an OS and there are routines written in other languages that we 
need to call or that need to call the Forth program. The usual solution 
is to set up a mutually-agreeable jump table and have both Forth and 
non-Forth memory regions.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#19371

Lauri Alanko wrote:

> In article <9309258.enKt5cl8Je@sunwukong.fritz.box>,
> Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>> Alex McDonald wrote:
>> > It's call relocation. It can be done at run time as well as load
>> > time.
> 
>> I'm not sure if this is really necessary today.  Private address
>> spaces are now the norm, and OSes have their rules how to allocate
>> memory for shared libraries, so when you specify an address in a
>> region that's unlikely to used for that, you get the mmap() request.
> 
> Well, there are still architectures without MMUs...

Yes, but they have become pretty rare, at least in the combination "has 
an OS".  The last one I saw was a Blackfin DSP, which did run Linux, but 
didn't have a MMU.

> More pertinently, the reason for relocatability is interoperability.
> Before the transition to ELF, shared libraries in Linux had fixed
> addresses, so there had to be a globally centralized registry where
> libraries were allocated a piece of address space to ensure that any
> libraries could coexist in a single process. It was reportedly a pain.

In ELF, only shared libraries are relocatible, programs aren't (they are 
not compiled with -fPIC).

> If your Forth program (or whatever) had single-handed control over the
> entire process, then sure, it could use fixed addresses. But modern
> programs are often composed from multiple components implemented in
> multiple languages, all linked together into a single address space in
> a single process. The only way this can work is if everyone plays nice
> and doesn't insist on getting a specific slice of the address space.

In Gforth, we pay the pain to be relocatible for being portable and 
having unforseen usecases.  But the typical Forth mentality is not to do 
this: Don't bent over backwards for unknown uses, do only what's needed.  
The ELF situation isn't that much different: Libraries need to be 
relocatible, because the other option is too painful to be implemented 
(and with ASLR, it's no longer something you really want to do, even if 
it wasn't painful).  But the main program isn't.  It comes first, so it 
can demand a specific location.

In that case, you just don't need the effort for relocation.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#19376

On Sat, 02 Feb 2013 16:32:46 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>In ELF, only shared libraries are relocatible, programs aren't (they are 
>not compiled with -fPIC).

Just to nitpick, ELF is the final binary format; it's perfectly
valid to to have a relocatable executable.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#19374

In article <kefhr3$roi$1@oravannahka.helsinki.fi>,
Lauri Alanko  <la@iki.fi> wrote:
>In article <9309258.enKt5cl8Je@sunwukong.fritz.box>,
>Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>> Alex McDonald wrote:
>> > It's call relocation. It can be done at run time as well as load time.
>
>> I'm not sure if this is really necessary today.  Private address spaces
>> are now the norm, and OSes have their rules how to allocate memory for
>> shared libraries, so when you specify an address in a region that's
>> unlikely to used for that, you get the mmap() request.
>
>Well, there are still architectures without MMUs...
>
>More pertinently, the reason for relocatability is interoperability.
>Before the transition to ELF, shared libraries in Linux had fixed
>addresses, so there had to be a globally centralized registry where
>libraries were allocated a piece of address space to ensure that any
>libraries could coexist in a single process. It was reportedly a pain.
>
>If your Forth program (or whatever) had single-handed control over the
>entire process, then sure, it could use fixed addresses. But modern
>programs are often composed from multiple components implemented in
>multiple languages, all linked together into a single address space in
>a single process. The only way this can work is if everyone plays nice
>and doesn't insist on getting a specific slice of the address space.

Instead of going in the very painful direction you're suggesting,
I would instead do a static link of my Forth program with a
relocatable library. The folklore is that static linking wastes a
lot of memory. 1. Prove it. 2. Kiss my Giga-*ss.
[In practice: my ciforth is very practical without any linking at all.
It runs on linuxes from the stone age.]

>
>Lauri

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]

#18961

In article <e5e8de00-d14b-4d1f-91d7-fc3abfb74bc2@bx10g2000vbb.googlegroups.com>,
Alex McDonald  <blog@rivadpm.com> wrote:
>On Jan 20, 11:46 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>> On Jan 20, 6:26 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>>
>> > Hugh Aguilar wrote:
>> > > Aren't the terms VM and TIL synonymous? Every VM is a TIL.
>>
>> > A threaded interpretative language means you have threaded code, i.e. a
>> > next is "goto *(ip)++" or something like that (indirect threaded means
>> > another indirection).  A VM can be byte-code, threaded code, or
>> > whatever, and may be implemented with a just in time compiler instead of
>> > a threaded code interpreter.
>>
>> Over on the Racket mailing list, I asked what the point of a VM and
>> just-in-time compiling was, and why not just compile into machine-code
>> (do the hard work at compile-time rather than run-time). I was told
>> (by Stephen Bloch, the guru over there), that the use of a VM allows
>> an executable to run on various processors without being recompiled
>> --- so long as there is a VM for that processor. To do this however,
>> the xt values can't be absolute addresses (as done in Forth's DTC and
>> ITC). The xt values have to be relative offsets (as done in Forth's C-
>> based token threading, or Pascal's byte-code).
>
>Who told you that last part? It's nonsense. DTC and ITC can be
>relative offset based; Win32Forth v4 is exactly that.

More over with the flexibility Intel offers it is possible to define
a virtual machine using absolute addresses in some Forth primitives
segment. (Not that anybody in his right mind would implement it,
just to prove Hugh wrong.)

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]

#18989

"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:ac332281-5f87-463a-8bcd-de34e1cb5f90@t6g2000pba.googlegroups.com...
>
> Over on the Racket mailing list, I asked what the point of a VM
> and just-in-time compiling was, and why not just compile into
> machine-code (do the hard work at compile-time rather than
> run-time). I was told (by Stephen Bloch, the guru over there),
> that the use of a VM allows an executable to run on various
> processors without being recompiled --- so long as there is
> a VM for that processor.

Hugh, tell me the truth.  Are you making fun of some of the people
here?  Unlike me and you, most here can't pick out a craftily
worded contradiction of logic even if it were to smack them on the
forehead...  It's probably a factor as to why they're religious.
Anyway, I'd swear you've posted variations of this little "test"
at least six times now.  If it's wasn't a test, you might want to
ask yourself why you keep posting the same thing over and over
again.

Obviously, "just-in-time compiling" compiles the code.  So,
claiming the code executes "without being recompiled" is _clearly_
an erroneous statement, either on your part or Mr. Bloch's.

IMO, there is no *real* point to either "just-in-time compiling"
or a VM.

A VM is a software version of a processor.  It re-implements
functionality the processor can already do, typically.  This means
a VM will always be slower than native code which executes
directly on the microprocessor.

"Just-in-time compiling" shifts the burden of compiling an
application from the developer to software being executed on the
user's machine.  Unfortunately, that slows down execution from the
user's perspective also by delaying execution until the
"just-in-time compiling" actually compiles some of the code.  This
might be painfully slow if the user has a slow machine.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#18991

On Jan 22, 8:18 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:

<pedantry snippage...>

>
> IMO, there is no *real* point to either "just-in-time compiling"
> or a VM.
>

Really?

> A VM is a software version of a processor.  It re-implements
> functionality the processor can already do, typically.  This means
> a VM will always be slower than native code which executes
> directly on the microprocessor.
>

What if performance is not the main metric? What if application
security (in terms of not crashing) is the main goal? You seem to have
an obsession with performance. Where I work, "must not fail" is tens
of millions of dollars more important than "must be fast". We couldn't
give a shit about its performance, quite frankly.

If a mission critical application that contains a bug (e.g. out of
bounds array index) runs on the metal, that bug may go undected for a
long long time (e.g. recent KDE bug that was fixed after 10 years and
2 months (though it was known about - nobody could be bothered to fix
it)).

If the code was running on a VM, that bug would immediately be caught
at run time, the precise location of the occurance of the bug would be
clearly shown, and the fix could be applied immediately. This could be
the difference between a plane falling out of the sky, or, er, not
falling out of the sky. It's a lot easier to debug your code in lab,
rather than picking through the wreckage of an aircraft. The VM could
be the difference between a watchdog trip on your car's engine
management system, leaving you stalled in the fast lane, or not
stalled in the fast lane.

To posit that "there is no *real* point" to a VM is somewhat naive,
unless you're trolling.

There's a point to JIT too, though there's less of a benefit (just my
opinion) - applications start up much much much faster if the entire
application does not have to be compiled end-to-end.

You know all of this. I think you've just got your troll hat on.

You've done Java in your long and illustrious career, right? .Net?

[toc] | [prev] | [next] | [standalone]

#18992

Mark Wills <forthfreak@gmail.com> wrote:
> There's a point to JIT too, though there's less of a benefit (just my
> opinion) - applications start up much much much faster if the entire
> application does not have to be compiled end-to-end.

The biggest purely technical advantage of a JIT is that compliation is
optimized for the exact environment in which a program is run, and the
characteristics of the dataset it's being run on.  You can't do that
ahead of time.  The most advanced JITs will even recompile a routine
that is live on the call stack.

Compare this with native compilers that typically have no idea of
which processor the code will be run on -- could be Pentium Pro, could
be K8, could be Sandy Bridge -- and have to do the best they can.
This isn't a problem when you're compiling a program for yourself, but
it is when you're distributing binaries.

Andrew.

[toc] | [prev] | [next] | [standalone]

#18995

On Jan 22, 9:31 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Mark Wills <forthfr...@gmail.com> wrote:
> > There's a point to JIT too, though there's less of a benefit (just my
> > opinion) - applications start up much much much faster if the entire
> > application does not have to be compiled end-to-end.
>
> The biggest purely technical advantage of a JIT is that compliation is
> optimized for the exact environment in which a program is run, and the
> characteristics of the dataset it's being run on.  You can't do that
> ahead of time.  The most advanced JITs will even recompile a routine
> that is live on the call stack.
>
> Compare this with native compilers that typically have no idea of
> which processor the code will be run on -- could be Pentium Pro, could
> be K8, could be Sandy Bridge -- and have to do the best they can.
> This isn't a problem when you're compiling a program for yourself, but
> it is when you're distributing binaries.
>
> Andrew.

There have always been classes of problem where JIT on a VM has been
used without calling it such. Case in point; dynamic regexes and that
Unix favourite, grep.

Interestingly, some JITs use the same backend as a static compilers;
Mono uses LLVM for instance. I looked at it for Forth code generation,
but it's a big learning curve and more suited to typed stack frame
languages.

[toc] | [prev] | [next] | [standalone]

#19013

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:QrOdnZqmZNr8wWPNnZ2dnUVZ_r6dnZ2d@supernews.com...
> Mark Wills <forthfreak@gmail.com> wrote:

> > There's a point to JIT too, though there's less of a benefit
> > (just my opinion) - applications start up much much much
> > faster if the entire application does not have to be compiled
> > end-to-end.
>
> The biggest purely technical advantage of a JIT is that
> compliation is optimized for the exact environment in
> which a program is run,

A compiler can do that, if implemented.  Most do.

> [...] and the characteristics of the dataset it's being run on.
> You can't do that ahead of time.

What language requires information from the dataset in order to
optimize the code?  ...  I.e., that defeats the purpose of having
code in the first place.  Separation of code and data affects all
sorts of computer science concepts:  Harvard architecture, data
independence, locality of reference, etc.

> The most advanced JITs will even recompile a routine
> that is live on the call stack.

Modern processors should be able to block that.  Active code on
the call stack is part of the typical method behind buffer
overflow exploits.

> Compare this with native compilers that typically have no idea
> of which processor the code will be run on -- could be Pentium
> Pro, could be K8, could be Sandy Bridge -- and have to do the
> best they can.

A compiler can query or be told what target to compile for.  I
prefer telling the compiler what to do instead of having it guess.
In the case of JIT, as an end-user, I can't tell the JIT what
target to compile for, if it's incorrect or there is some issue
with the generated code for the appropriate target.  I'm stuck
with whatever was implemented, even if broken.

> This isn't a problem when you're compiling a program for
> yourself, but it is when you're distributing binaries.

No, it's not a problem for code coded in assembly.  Checking the
execution target and executing appropriate code is done all the
time in assembly.  It's a problem for lazy HLL programmers who
refuse to code multiple versions of a routine for each target.
It's the "one and done" mentality.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#19025

Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:QrOdnZqmZNr8wWPNnZ2dnUVZ_r6dnZ2d@supernews.com...
>> Mark Wills <forthfreak@gmail.com> wrote:
> 
>> > There's a point to JIT too, though there's less of a benefit
>> > (just my opinion) - applications start up much much much
>> > faster if the entire application does not have to be compiled
>> > end-to-end.
>>
>> The biggest purely technical advantage of a JIT is that
>> compliation is optimized for the exact environment in
>> which a program is run,
> 
> A compiler can do that, if implemented.  Most do.

You haven't been paying attention.

>> [...] and the characteristics of the dataset it's being run on.
>> You can't do that ahead of time.
> 
> What language requires information from the dataset in order to
> optimize the code? 

All of them.  Compilers have to guess all the time about the dynamic
execution frequency of code.  Sometimes they get it right, sometimes
not.  When you have a JIT, you know.

> ...  I.e., that defeats the purpose of having code in the first
> place.  Separation of code and data affects all sorts of computer
> science concepts: Harvard architecture, data independence, locality
> of reference, etc.

What rubbish.  The whole point is that different optimizations are
possible if you know the dynamic types of the objects you're working
on.  And, later in the run, you can recompile as things change.  You
can specially optimize hot paths through the code, and so on.

>> The most advanced JITs will even recompile a routine that is live
>> on the call stack.
> 
> Modern processors should be able to block that.  Active code on
> the call stack is part of the typical method behind buffer
> overflow exploits.

No, the code is not on the call stack: the activation record is on the
call stack.

>> Compare this with native compilers that typically have no idea
>> of which processor the code will be run on -- could be Pentium
>> Pro, could be K8, could be Sandy Bridge -- and have to do the
>> best they can.
> 
> A compiler can query or be told what target to compile for.  I
> prefer telling the compiler what to do instead of having it guess.
> In the case of JIT, as an end-user, I can't tell the JIT what
> target to compile for, if it's incorrect or there is some issue
> with the generated code for the appropriate target.

It's not incorrect.  The JIT knows what machine it's running on;
there's no need to guess.

> I'm stuck with whatever was implemented, even if broken.
> 
>> This isn't a problem when you're compiling a program for
>> yourself, but it is when you're distributing binaries.
> 
> No, it's not a problem for code coded in assembly.  Checking the
> execution target and executing appropriate code is done all the time
> in assembly.  It's a problem for lazy HLL programmers who refuse to
> code multiple versions of a routine for each target.  It's the "one
> and done" mentality.

This is meaningless nonsense.  The whole point of a compiler, JIT or
otherwise, is to generate code from a high-level language.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19153

On 1/22/2013 2:36 PM, Rod Pemberton wrote:
> "Andrew Haley"<andrew29@littlepinkcloud.invalid>  wrote in message
> news:QrOdnZqmZNr8wWPNnZ2dnUVZ_r6dnZ2d@supernews.com...
>>
>> The biggest purely technical advantage of a JIT is that
>> compliation is optimized for the exact environment in
>> which a program is run,
>
> A compiler can do that, if implemented.  Most do.

Yep, and that code runs optimally on just that one machine.  Andrew is 
talking about using a common distribution and the JIT optimizing the 
execution for whatever machine it is run on.  In essence, the JIT is the 
compiler back end, but because it is running in only one environment, 
your machine, it can optimize for exactly that one environment without 
any input from you.

...snip...

>> The most advanced JITs will even recompile a routine
>> that is live on the call stack.
>
> Modern processors should be able to block that.  Active code on
> the call stack is part of the typical method behind buffer
> overflow exploits.

You are confused.  The term "buffer overflow" should be the clue.  They 
depend on writing to code space by overflowing a buffer in data space 
and having that data write into the executable region.  At no time does 
this exploit expect to be able to execute code "on the stack".  The two 
concepts are totally unrelated.


>> Compare this with native compilers that typically have no idea
>> of which processor the code will be run on -- could be Pentium
>> Pro, could be K8, could be Sandy Bridge -- and have to do the
>> best they can.
>
> A compiler can query or be told what target to compile for.  I
> prefer telling the compiler what to do instead of having it guess.
> In the case of JIT, as an end-user, I can't tell the JIT what
> target to compile for, if it's incorrect or there is some issue
> with the generated code for the appropriate target.  I'm stuck
> with whatever was implemented, even if broken.

Isn't that true for all software?  If it is broken, it is broken.


>> This isn't a problem when you're compiling a program for
>> yourself, but it is when you're distributing binaries.
>
> No, it's not a problem for code coded in assembly.  Checking the
> execution target and executing appropriate code is done all the
> time in assembly.  It's a problem for lazy HLL programmers who
> refuse to code multiple versions of a routine for each target.
> It's the "one and done" mentality.

You mean adding the specifics of the target optimization to the run time 
code?  That would be *very* inefficient.

Multiple code versions is not a matter of being lazy, it is a logistics 
nightmare.  Most distributions have perhaps two versions, 32 bit and 64 
bit.  Imagine the trouble in managing some dozen or more variations! 
The users will never know which to download.

Rick

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.forth

csiph-web