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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#19344

On 31.01.2013 21:47, Mark Wills wrote:
> On Jan 31, 8:03 pm, "A. K." <a...@nospam.org> wrote:
>> On 31.01.2013 20:41, rickman wrote:
>>
>>> Your reply is a non-sequitur.  You say your "DSL" lets you perform
>>> parallel execution.  So how is that different from Forth?  Or maybe I
>>> don't understand what you are comparing your DSL to?
>>
>> To put it simply:
>>
>> OPERATOR( <commands1> | <commands2> | <commands3> )
>>
>> will be compiled to executing the three Forth-like command sequences in
>> parallel threads or CPU cores. Their outputs will be stacked. When the
>> last command sequence has finished, parallelism ends, and OPERATOR is
>> executed on the stack. It is a rather primitive scheme, but the compiler
>> has to know the arity of operators of course.
>>
>> AFAIK Forth has no commands for controlling parallel execution at all.
>
> PARALLEL FORTH: The new approach
>
> Michael Montvelishsky, Saransk Russia
>
> http://www.ultratechnology.com/4thpar.html
>

Yes, thanks for the link, I seem to remember this one.

Our scheme is not as generally useful as Michael's proposed scheme. We 
did not bother about environments or user variables, just the stacks.

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

#19000

On Jan 22, 12:31 pm, Mark Wills <forthfr...@gmail.com> wrote:
> On Jan 22, 11:52 am, "A. K." <a...@nospam.org> wrote:
>
>
>
>
>
>
>
>
>
> > On 22.01.2013 10:10, Mark Wills wrote:
>
> > > 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.
>
> > This is the best statement I've read in c.l.f. since long.
>
> > Nearly all control systems today are graphically "programmed" by
> > connecting software blocks in CAE systems. Unparamaterized/unconnected
> > I/Os are detected immediately (so there is nothing like stack mismatch
> > as in Forth development). Only thoroughly tested blocks with inherent
> > self-monitoring and error-detection are provided in libraries. Many DCS
> > even go as far as not providing a user programming language at all, you
> > have to build macros from those blocks.
>
> > Benefit: Code runtime is slow but safe. And during engineering you don't
> > waste time with software debugging, you can visually concentrate on your
> > algorithms.
>
> Fully agree. And in most (if not all) cases, the code that is
> developed, be it ladder logic, sequential function charts, and the
> like all run inside a VM. That way, if the worst *should* happen and
> the VM falls over, your *server* _does not_ fall over, it can detect
> the VM crash and re-start it. Allen Bradley PLCs run a number of VMs
> on a single PLC - one for each task. If a task/program crashes (I've
> *never* seen it happen in over 20 years of experience) the rest of the
> system stays up, no problem at all.
>
> If you study IEC 61131 part 3 you'll find the definition for a virtual
> assembly languge called IL (Instruction List) which is used in control
> systems - SCADA systems, DCS, ICSS and the like. IL runs in a virtual
> machine. Ladder logic, FBDs etc all compile down to IL.

I'd dispute the "safe" bit. There appear to be a number of PLC
vulnerabilities; for one, Stuxnet appears to have been designed to
attack SCADA based PLCs.

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

#19004

Alex McDonald wrote:

>> If you study IEC 61131 part 3 you'll find the definition for a
>> virtual assembly languge called IL (Instruction List) which is used
>> in control systems - SCADA systems, DCS, ICSS and the like. IL runs
>> in a virtual machine. Ladder logic, FBDs etc all compile down to IL.
> 
> I'd dispute the "safe" bit. There appear to be a number of PLC
> vulnerabilities; for one, Stuxnet appears to have been designed to
> attack SCADA based PLCs.

Well, but by changing their program.  The program Stuxnet installed 
worked as designed (stable, not crashing), and caused the centrifuges to 
wear down pretty fast, by driving them to a point where they started to 
vibrate.  Usually, you just do the logic the other way round: drive them 
to a point where they run smoothly.

PLCs are "crash-proof", because the programs you can write with ladder 
logic are severely limited in what you can do.  But you still can get 
your program logic wrong, ruining your equipment (which is what 
Stuxnet's purpose is).

The question whether a PLC is implemented as VM or as JIT doesn't 
matter.  Just as it doesn't matter when your programming language 
semantics has array bound checks - both a VM and a JIT can check for 
array bounds.  And both of them can store enough debugging informations 
so that when you are out of bounds, the cursor in your IDE will stay 
right on the index equation.

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

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

#18998

On Jan 22, 11:52 am, "A. K." <a...@nospam.org> wrote:
> Benefit: Code runtime is slow but safe. And during engineering you don't
> waste time with software debugging, you can visually concentrate on your
> algorithms.

Exactly. You hook up your inputs and outputs and it just works.

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

#19012

"Mark Wills" <forthfreak@gmail.com> wrote in message
news:d44429cc-c638-49ce-b490-74005fea0faf@z9g2000vbx.googlegroups.com...
> On Jan 22, 8:18 am, "Rod Pemberton"
<do_not_h...@notemailnotz.cnm>
> wrote:

> > 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?

Then, you 1) use the security features of the processor you're
using which likely has what you want, or 2) buy a custom processor
to fit your needs, e.g., like the military.

> You seem to have an obsession with performance.

No, I believe it's *stupid* to re-implement what's already present
in the microprocessor.  The PC microprocessor wars are over.
Intel/AMD won for the PC.  ARM is leading in mobile platforms.
I.e., there are only couple of primary microprocessor targets for
the entire civilian market.  A VM isn't needed to support a dozens
of different processors anymore...  So, whenever someone
implements a VM nowadays, it's frequently for a single
microprocessor target.  What's the point of that?  Slow code?
Sand-box?  Native code can be sand-boxed too.

> 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)).

What type of cheap, pitiful processor are you using that can't
check array bounds?  Even the "lowly" x86 has had that capability
for _decades_ ...  Now, whether a C compiler or some other high
level language actually _uses_ that functionality is a different
issue.  Most don't.  It's usually up to the programmer to do so...

> 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.

That's untrue.  You've made a few assumptions and taken them
as truth.  The first is that the bug is triggered at runtime so it
can be caught.  It might not be triggered for a decade or
ever.  The second is that the bug is serious enough that it needs
to be fixed or caught.  It might not be.  Some other undectable
bug might be what's actually important.  In some other cases, a
bug, intentional or not, may be required for proper operation of
the code.  The third is that the VM you're using is capable of
detecting such an error.  It might be.  It might not be.
Hopefully, it is.  However, a blanket statement that all VMs are
capable of catching such errors is ludicrous.  Most VMs aren't
designed for security.  Most are designed for executing a
language.  If they are designed for anything else, it's typically
for speed, not security.

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

No, your statement is trolling.  You know full well that there are
numerous processors that implement everything you mentioned and
everything you desire in terms of security in hardware.  It's just
an issue of money.  If tens of millions of dollars are at stake as
claimed, then maybe the company that employs you should consider
such a processor, or a better class of machine, etc.  If one bug
could cost your company say $5 million USD, then that or twice
that should be the range of machine you're using.

> There's a point to JIT too, [...]

Inefficiency?  Laziness?  Redistribution of work? costs?

> 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.

That's like claiming a compressed executable which must be
decompressed prior to execution starts up faster too...  How can
more work needing to be done before the code can execute be faster
somehow?

A JIT compiler must compile every bit of code that gets executed
just prior to execution.  This incremental compilation is called
slowness.  Also, that code isn't saved.  If I go to a website and
use some part of a JIT application, the code I used gets compiled,
on that day.  If I go back to the same website the next day and
use the same part of a JIT application, the same code I used gets
compiled again on the next day.  Next day, same thing, over and
over again.  What's the point in that?

Personally, I think DEC's FX!32 should be considered to be the
"original" application of JIT.  It converted x86 binary to Alpha
binary.  So, technically, it was a binary-to-binary translator,
not JIT.  Also, it was combined with a peephole binary instruction
optimizer.  But, the effects experienced by the user are
essentially the same for FX!32 as for JIT.  Slowness, followed by
an increase in speed, if the same code that was translated and
optimized is used again, or more slowness if new code must be
translated and optimized.  The incremental translation and
optimization at runtime is what caused users to experience
slowness.  JIT does the exact same thing.  Actually, the effects
of FX!32 are probably far better than JIT, since the translated
and optimized code for the DEC was saved and re-used, not flushed
like in a browser for a JIT application.  Eventually, all or most
of an application was translated to optimized Alpha instructions.
Of course, if the code had been compiled to Alpha instructions in
the first place, then slowness would've been at a minimum.


Rod Pemberton

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

#19026

Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> Personally, I think DEC's FX!32 should be considered to be the
> "original" application of JIT.

And you're wrong, as a moment's perusal of the Wikipedia page would
have told you.

Andrew.

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

#19039

On Jan 22, 7:35 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Mark Wills" <forthfr...@gmail.com> wrote in message
>
> news:d44429cc-c638-49ce-b490-74005fea0faf@z9g2000vbx.googlegroups.com...> On Jan 22, 8:18 am, "Rod Pemberton"
>
> <do_not_h...@notemailnotz.cnm>
>
> > wrote:
> > > 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?
>
> Then, you 1) use the security features of the processor you're
> using which likely has what you want, or 2) buy a custom processor
> to fit your needs, e.g., like the military.
>

Well, hold on, I'll just go give Allen Bradley and Siemens a call and
tell them they're doing it all wrong. Is it okay if I pass them your
contact information, since you clearly know a lot more about it than
they do?

> > You seem to have an obsession with performance.
>
> No, I believe it's *stupid* to re-implement what's already present
> in the microprocessor.  The PC microprocessor wars are over.

What relevance do the microprocessor wars have to Virtual Machines and
Just-In-Time compiler technology?

> Intel/AMD won for the PC.  ARM is leading in mobile platforms.
> I.e., there are only couple of primary microprocessor targets for
> the entire civilian market.

Ah, so there are only PCs and mobile ‘phones. I see, I get it now.
That means the PLC in front of me is purely a figment of my
imagination. It must be the strong coffee. Satellite environmental
control systems, satellite thruster control systems, x-ray machines,
MRI machines, none of these exist.

> A VM isn't needed to support a dozens
> of different processors anymore...

A VM doesn't support *any* processor. You seem to be under the
impression that a VM is an emulator so that I can run Z80 on a x86.
It's nothing of the sort. It's a virtual processor, that has never
existed in silicon. It's a custom made processor, in *software* with
its own instruction set, addressing modes, yadda yadda yadda.

> So, whenever someone
> implements a VM nowadays, it's frequently for a single
> microprocessor target.

You mean like the Java VM, which *only* runs on Intel,  Arm and Power
PC?

A VM is not an emulator. We're not talking about playing GameBoy games
on your PC. The target is not *another microprocessor*. Please tell me
which "microprocessor" the Microsoft .Net VM is targeting? Please
provide a part number and a link to a datasheet so that I can go build
a .Net system in hardware.

> What's the point of that?  Slow code?
> Sand-box?  Native code can be sand-boxed too.

Yes it can. Modern x86 processors have had virtualisation support for
a number of years. Congratulations. You said something that is
actually true. Amazing.

>
> What type of cheap, pitiful processor are you using that can't
> check array bounds?  Even the "lowly" x86 has had that capability
> for _decades_ ...

I'm not using any processor. I'm using a virtual, implemented-in-
software processor.

Please indicate a part number and a datasheet of a processor that has
native machine code support for arrays (and thus can detect an out of
bounds array access attempt). I am not aware of any. I know that
modern Intel parts are very clever, but (to my knowledge (happy to be
proved wrong)) they don't have support for arrays at the instruction
set level. In fact, I'm not aware of any *silicon* processor that
does. Some processors have various protected modes, and have process/
task isolation, but none (that I am aware of) support arrays.

> Now, whether a C compiler or some other high
> level language actually _uses_ that functionality is a different
> issue.  Most don't.  It's usually up to the programmer to do so...
>

Right. So it has a feature that I can't access under normal
circumstances. Great.

Though I have to say, I think you're just bullshitting. Are you
telling me that (for example) all the buffer over-run bugs in Windows/
Linux/Apache/blah blah that have caused so much pain over the years -
people's data getting raided, bank accounts being plundered, spyware
being installed, malware being installed, botnets etc could have been
prevented with a simple compiler switch? Wow! That's awesome, Rod.
Man, you really are a freaking genius dude! Why didn't you say
something decades ago? I tell you what, we have a pretty much direct
line to Microsoft here, we pay 'em thousands a year for high-priority
support. I'll just go give 'em a call and tell them that all their
problems are solved, for Rod Pemberton (all hail) knows the secret
solution, the secret missing ingredient that will fix all their bugs
overnight.

But first.... I'm going to go and buy some Microsoft shares on the
NYSE, because believe me man, this is going to be big big news.

In fact, while I'm at it, I seem to recall that Cisco have their fair
share of hassle from un-checked array access in their code, so I'll go
give them a call too - after I've picked up some shares...

[ 15 minutes later, and $10,000 dollars invested ]

"Hey, is that Microsoft? Rod Pemberton told me all you have to do is
enable bounds checking on your compilers, and then all your software
will work!"

"You're kidding, right? Is this a joke?"

"I know, I know! Bloody *amazing* isn't it. Who would have thought it?
I picked up some shares today. When are you going to do a press
release? Don't forget to credit Pemberton, and pass his name onto
Steve Ballmer, you could do with hiring someone like him. He's
freaking smart man!"

"Dude, say off the computer when you're high, okay?"

<click>

"Hello? Hello?"

Hmmm... Seems they weren't too impressed with your theory Rod. But
hey, I tried my best. I'll sit on the shares for a while, though I
don't hold out much hope of turning a profit. The Microsoft Surface
thing isn't going too well...

> > 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.
>
> That's untrue.  You've made a few assumptions and taken them
> as truth.  The first is that the bug is triggered at runtime so it
> can be caught.

Well, if an array was illegally accessed at run-time, then it *would*
be caught, wouldn't it? At what other point *can* an array be
illegally accessed? During compile time? While writing the source?
Perhaps it's when I'm thinking about the problem on the train, or on
the toilet?


> It might not be triggered for a decade or
> ever.

Okay. But if it *is* triggered after a decade, then it would be at run-
time, wouldn't it?

> The second is that the bug is serious enough that it needs
> to be fixed or caught.  It might not be.  Some other undectable
> bug might be what's actually important.

Please cite an example of a bug that is undetectable. Wow. I'm really
learning a lot here. Glad I logged on. No, really.

> In some other cases, a
> bug, intentional or not, may be required for proper operation of
> the code.

-------------------------------------------------

** EXTRA EXTRA - READ ALL ABOUT IT **
PROGRAMMER CLAIMS BUGS ARE NEEDED
In some cases, intentional bugs are required for the correct operation
of code, Rod Pemberton, a computer programming expert from America
claimed today. In an inocuous, though revalatory post on Usenet,
Pemberton claimed that in some cases, intentionally flawed code may
actually be necessary to ensure that a software-based system runs
correctly.

The claim has raised interest and controversy in equal measure in
programming circles. Microsoft, when approached for a comment today
were somewhat sceptical. A spokesman for the Redmond based company
said: "Well, we've been writing buggy code for decades, and to be
honest, I don't think it's really helped us a whole lot. In fact, we
employ entire departments just to conduct code quality reviews. I
guess you could argue that bad code is good for the economy, since it
keeps people employed, but to be honest, if you really pushed us, I
think we'd have to say that we'd really prefer it if our code, you
know, just worked."

Boeing were more philosophical however. When approached for comment, a
spokesman said "Gee, that's really interesting. We employ three teams
of private third-party contractors, working independently to come up
with triple-redundant systems for things like our flight control
systems. I have to say, it costs us millions upon millions of dollars
to get these software systems right, but you know, we still have the
occasional glitch that we just can't understand. So this Pemberton guy
is saying just, you know, sprinkle the occasional bug in there and
it'll fix it. Hmmm... This could save us millions a year. Do you have
this guys 'phone number?"

Rod Pemberton was unavailable for comment as this article went to
press.

-------------------------------------------------


> The third is that the VM you're using is capable of
> detecting such an error.

Oh yes of course. Because both the Java and .Net VMs cannot detect
such an error. Nor can the Allen Bradley, Siemens, ABB and Omron VMs
that run their 61131 code.

Can you cite an example of a VM that can't detect such an error? I
just cited six that can.

Do you think that, gee, you know, just perhaps the *entire point* of
running code on a VM is so that you *can* trap errors that a native
piece of silicon cannot trap?

> It might be.  It might not be.
> Hopefully, it is.  However, a blanket statement that all VMs are
> capable of catching such errors is ludicrous.

I don't think it's any more ludicrous than saying that they can't.

> Most VMs aren't
> designed for security.  Most are designed for executing a
> language.

Oh dear. I don't know why I'm bothering. They do *not* execute a
language. They execute compiled code. For Christ sakes, the .Net VM is
*langauge independent* you idiot. In .Net you can write your code in
C#, VB, F#, ASP, and J#.

"Common Language Runtime engine
The Common Language Runtime (CLR) serves as the execution engine of
the .NET Framework. All .NET programs execute under the supervision of
the CLR, guaranteeing certain properties and behaviors in the areas of
memory management, security, and exception handling."

http://en.wikipedia.org/wiki/.NET_Framework

Note that last sentence, Rod: "guaranteeing certain properties and
behaviors in the areas of memory management, security, and exception
handling."

Wow! Who'da thunk it? Hugh? Bloody clever what you can do these days,
isn't it?

> If they are designed for anything else, it's typically
> for speed, not security.
>

But in an earlier statement above, you said: <drum roll please...>

"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. "

Hmmm... *Always* be slower you said. Then you say "If they are
designed for anything else, it's typically for speed, not security."

You also said:

"So, whenever someone
implements a VM nowadays, it's frequently for a single
microprocessor target.  What's the point of that?  Slow code?
Sand-box?  Native code can be sand-boxed too."

Slow code? Did you say slow code? But just above you said:

"If they are designed for anything else, it's typically
for speed, not security."

So which is it? Slow code or fast code? Pick one.

Do you have any idea just how much of an ill-informed bullshit
spouting idiot you are looking right now? I would caution you against
making statements about subjects upon which you are ill informed. You
know all this UseNet stuff is essentially archived forever, right? I
would hate for you to be asked to justify your comments on this
subject in a job interview, when presented with a print-out of this
thread. That might be a "make my excuses and leave" moment right
there...

> > To posit that "there is no *real* point" to a VM
> > is somewhat naive, unless you're trolling.
>
> No, your statement is trolling.  You know full well that there are
> numerous processors that implement everything you mentioned and
> everything you desire in terms of security in hardware.

No I don't. Really I don't. I know of processors that can segregate
memory space between different *processes* or tasks. I know of earlier
mini-computer type processors that implement ring-based security that
can prevent a crashed process from crashing other processes, but
that's process segregation. I know of no processor that can (for
example) within a process detect an out of bounds array access,
because I know of no processor that has a concept of an array, much
less a typed array. VMs, on the other hand, do. That's why they're
used, because the underlying processor doesn't have a particular
facility.


> It's just
> an issue of money.  If tens of millions of dollars are at stake as
> claimed, then maybe the company that employs you should consider
> such a processor, or a better class of machine, etc.  If one bug
> could cost your company say $5 million USD, then that or twice
> that should be the range of machine you're using.

There's no need. We already have working systems, based on VMs. They
are manufactured by companies such as Allen Bradley, who are a fortune
500 company, if I'm not mistaken. So thanks for the advice, but I
think we'll just keep buying the stuff from the folks that have proven
that they know what they're doing.
>
> > There's a point to JIT too, [...]
>
> Inefficiency?  Laziness?  Redistribution of work? costs?
>

Well, given that you said above that VMs are implemented for
performance reasons, I find your inefficiency claim somewhat
contradictory.


> > 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.
>
> That's like claiming a compressed executable which must be
> decompressed prior to execution starts up faster too...

Excuse me? Are you on psychotropics buy any chance? No wait a minute,
perhaps it's bath salts. Yep. Bath salts. You're clearly
hallucinating. In what way is de-compression of pre-compiled
executable code comparable to byte-code for use by a VM? Please
elucidate.

> How can
> more work needing to be done before the code can execute be faster
> somehow?
>

I said "start up much much much faster". Note the words "start" and
"up". Please re-read.

> A JIT compiler must compile every bit of code that gets executed
> just prior to execution.  This incremental compilation is called
> slowness.

As opposed to the "speed" that you cited earlier. You've contradicted
yourself so many times in the same post that I don't if I'm coming or
going. This alludes to my bath salts suspicion. Have you seen the film
Sybil, starring Sally Field?


> Also, that code isn't saved.  If I go to a website and
> use some part of a JIT application, the code I used gets compiled,
> on that day.  If I go back to the same website the next day and
> use the same part of a JIT application, the same code I used gets
> compiled again on the next day.  Next day, same thing, over and
> over again.  What's the point in that?

Wrong wrong wrong wrong. That would be interpretation, not
compilation. The clue is in the fact that the two words are actually
different. Here: Try it. “Interpretation. Compilation”. I appreciate
that they have “tion” in common, but trust me, they are different
words with different meanings.

The compiled code, once compiled, is cached. Don't assume because an
internet web site is stateless that the VM is also stateless. I
suppose you also think that the same code is compiled over and over
again as different users log on to the web site and call up the same
pages? You do, don't you?

>
> Personally, I think DEC's FX!32 should be considered to be the
> "original" application of JIT.  It converted x86 binary to Alpha
> binary.  So, technically, it was a binary-to-binary translator,
> not JIT.
> Also, it was combined with a peephole binary instruction
> optimizer.
> But, the effects experienced by the user are
> essentially the same for FX!32 as for JIT.  Slowness, followed by
> an increase in speed, if the same code that was translated and
> optimized is used again, or more slowness if new code must be
> translated and optimized.

That's certainly true, but that does seem to be improving - though I
concede that that might simply be down to faster CPUs rather than
improvements in JIT technology.

> The incremental translation and
> optimization at runtime is what caused users to experience
> slowness.

True. You said something that makes sense. I congratulate you. I do
concede that in something like an arcade game, that would be
unacceptable; different horses for different courses. In a word
processor you probably wouldn't notice too much - a drop down menu
might take a little longer to open on the first click, but it's not
the end of the world. The spell check loop might execute at 50% speed
for the lookup of the first word, but near-native speed after that.

In other uses, such as process control, it's not so much of an issue.
If you are controlling the temperature of an oven with a PID loop and
your integral function takes too long to execute on the first
invocation, it's not going to make any difference at all. If you're
looking for the Higgs Boson, then yeah, you might want to rethink.

> JIT does the exact same thing.  Actually, the effects
> of FX!32 are probably far better than JIT, since the translated
> and optimized code for the DEC was saved and re-used, not flushed
> like in a browser for a JIT application.

Unsubstantiated drivel, as evidenced by your use of the word
"probably". You're just spouting a stream-of-conciousness drivel,
aren't you?

Compiled code is not flushed in web applications either. It's costly
to compile it, so why would you throw it away? You're simply
incorrect. Simple as that. Just because a web server is stateless and
is essentially idle when not serving pages does *not* mean that the
underlying compiled code is dropped with each serving of a page. Do
you not think that that simple optimization - that of compiling code
only once - might just have possibly occurred in the minds of the
people that were developing the technology in the first place? I mean,
you're good Rod, but hey, let's give someone else some credit too.

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

#19042

Mark Wills <forthfreak@gmail.com> wrote:
> On Jan 22, 7:35 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> wrote:

> Please indicate a part number and a datasheet of a processor that has
> native machine code support for arrays (and thus can detect an out of
> bounds array access attempt). I am not aware of any.

I think the point isn't so much that VMs can detect array bounds
accesses, but that there is no way to form an unchecked array access.

> No I don't. Really I don't. I know of processors that can segregate
> memory space between different *processes* or tasks. I know of
> earlier mini-computer type processors that implement ring-based
> security that can prevent a crashed process from crashing other
> processes, but that's process segregation. I know of no processor
> that can (for example) within a process detect an out of bounds
> array access, because I know of no processor that has a concept of
> an array, much less a typed array.

Well, you do now: the Burroughs 5500/6700 and its descendants.  Still
in existence, and very influential on Forth and many other virtual
machines.

> The compiled code, once compiled, is cached.

It's not a good idea to overgeneralize on this topic.  Some VMs do,
some don't.

Andrew.

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

#19043

On Jan 23, 10:43 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Well, you do now: the Burroughs 5500/6700 and its descendants.  Still
> in existence, and very influential on Forth and many other virtual
> machines.
>

Thank you Andrew. That's one example. Rod said "numerous". Any more
examples?

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

#19045

Mark Wills <forthfreak@gmail.com> wrote:
> On Jan 23, 10:43?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Well, you do now: the Burroughs 5500/6700 and its descendants.  Still
>> in existence, and very influential on Forth and many other virtual
>> machines.
> 
> Thank you Andrew. That's one example. Rod said "numerous". Any more
> examples?

Not many current ones, but there were quite a few in the past.  The
ICL 2900 was notable.

I'm not sure that the distinction between physical and virtyal
machines matters much now.  It's blurred because the current
instruction sets are really virtualized: there's a RISC core with a
bunch of execution units and register sets, and the instructions are
decoded into the uops that the core executes.  There's no hard
correspondence between the instructions in the ISA and any physical
resources.

A JVM (or whatever) is just another layer.

Andrew.

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

#19053

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> I'm not sure that the distinction between physical and virtyal
> machines matters much now. ...
> A JVM (or whatever) is just another layer.

No wait, the idea of the JVM is that even malicious code can't access
memory unsafely or do other bad operations, despite trying hard.  As
someone said, it's not enough that checked lookups are available;
unchecked lookups have to be unavailable.  

Erlang (a cool language I've been playing with recently) has arbitrary
precision arithmetic as part of its VM instruction set, I think.  That
would be decidedly unphysical.  I should check on that, though.  I
wonder what happens if there's a process switch in the middle of a
bignum multiplication, for example.

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

#19059

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I'm not sure that the distinction between physical and virtyal
>> machines matters much now. ...
>> A JVM (or whatever) is just another layer.
> 
> No wait, the idea of the JVM is that even malicious code can't access
> memory unsafely or do other bad operations, despite trying hard.

That's one of the ideas of a JVM; it's also one of the ideas of
the B6700 machines, as discussed.  

> As someone said, it's not enough that checked lookups are available;
> unchecked lookups have to be unavailable.

I said that; others probably did too.

Andrew.

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

#19415

On Wed, 23 Jan 2013 09:19:41 -0600, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

> Mark Wills <forthfreak@gmail.com> wrote:
> > On Jan 23, 10:43?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
<snipped: array bounds checking in actual CPUs vs VMs>

> >> Well, you do now: the Burroughs 5500/6700 and its descendants.  Still
> >> in existence, and very influential on Forth and many other virtual
> >> machines.
> > 
> > Thank you Andrew. That's one example. Rod said "numerous". Any more
> > examples?
> 
> Not many current ones, but there were quite a few in the past.  The
> ICL 2900 was notable.
> 
Also DEC VAX. Which had a range of models from high-end more in
silicon to low-end more in microcode, especially the CISCier insns.

> I'm not sure that the distinction between physical and virtyal
> machines matters much now.  It's blurred because the current
> instruction sets are really virtualized: there's a RISC core with a
> bunch of execution units and register sets, and the instructions are
> decoded into the uops that the core executes.  There's no hard
> correspondence between the instructions in the ISA and any physical
> resources.
> 
*more* blurred now, but that has always been some fuzziness.

> A JVM (or whatever) is just another layer.
> 
> Andrew.

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

#19154

On 1/23/2013 5:21 AM, Mark Wills wrote:
> On Jan 22, 7:35 pm, "Rod Pemberton"<do_not_h...@notemailnotz.cnm>
> wrote:
>> "Mark Wills"<forthfr...@gmail.com>  wrote in message
>>
>> news:d44429cc-c638-49ce-b490-74005fea0faf@z9g2000vbx.googlegroups.com...>  On Jan 22, 8:18 am, "Rod Pemberton"
>>
>> <do_not_h...@notemailnotz.cnm>
>>
>>> wrote:
>>>> 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?
>>
>> Then, you 1) use the security features of the processor you're
>> using which likely has what you want, or 2) buy a custom processor
>> to fit your needs, e.g., like the military.
>>
>
> Well, hold on, I'll just go give Allen Bradley and Siemens a call and
> tell them they're doing it all wrong. Is it okay if I pass them your
> contact information, since you clearly know a lot more about it than
> they do?
>
>>> You seem to have an obsession with performance.
>>
>> No, I believe it's *stupid* to re-implement what's already present
>> in the microprocessor.  The PC microprocessor wars are over.
>
> What relevance do the microprocessor wars have to Virtual Machines and
> Just-In-Time compiler technology?
>
>> Intel/AMD won for the PC.  ARM is leading in mobile platforms.
>> I.e., there are only couple of primary microprocessor targets for
>> the entire civilian market.
>
> Ah, so there are only PCs and mobile ‘phones. I see, I get it now.
> That means the PLC in front of me is purely a figment of my
> imagination. It must be the strong coffee. Satellite environmental
> control systems, satellite thruster control systems, x-ray machines,
> MRI machines, none of these exist.
>
>> A VM isn't needed to support a dozens
>> of different processors anymore...
>
> A VM doesn't support *any* processor. You seem to be under the
> impression that a VM is an emulator so that I can run Z80 on a x86.
> It's nothing of the sort. It's a virtual processor, that has never
> existed in silicon. It's a custom made processor, in *software* with
> its own instruction set, addressing modes, yadda yadda yadda.
>
>> So, whenever someone
>> implements a VM nowadays, it's frequently for a single
>> microprocessor target.
>
> You mean like the Java VM, which *only* runs on Intel,  Arm and Power
> PC?
>
> A VM is not an emulator. We're not talking about playing GameBoy games
> on your PC. The target is not *another microprocessor*. Please tell me
> which "microprocessor" the Microsoft .Net VM is targeting? Please
> provide a part number and a link to a datasheet so that I can go build
> a .Net system in hardware.
>
>> What's the point of that?  Slow code?
>> Sand-box?  Native code can be sand-boxed too.
>
> Yes it can. Modern x86 processors have had virtualisation support for
> a number of years. Congratulations. You said something that is
> actually true. Amazing.
>
>>
>> What type of cheap, pitiful processor are you using that can't
>> check array bounds?  Even the "lowly" x86 has had that capability
>> for _decades_ ...
>
> I'm not using any processor. I'm using a virtual, implemented-in-
> software processor.
>
> Please indicate a part number and a datasheet of a processor that has
> native machine code support for arrays (and thus can detect an out of
> bounds array access attempt). I am not aware of any. I know that
> modern Intel parts are very clever, but (to my knowledge (happy to be
> proved wrong)) they don't have support for arrays at the instruction
> set level. In fact, I'm not aware of any *silicon* processor that
> does. Some processors have various protected modes, and have process/
> task isolation, but none (that I am aware of) support arrays.
>
>> Now, whether a C compiler or some other high
>> level language actually _uses_ that functionality is a different
>> issue.  Most don't.  It's usually up to the programmer to do so...
>>
>
> Right. So it has a feature that I can't access under normal
> circumstances. Great.
>
> Though I have to say, I think you're just bullshitting. Are you
> telling me that (for example) all the buffer over-run bugs in Windows/
> Linux/Apache/blah blah that have caused so much pain over the years -
> people's data getting raided, bank accounts being plundered, spyware
> being installed, malware being installed, botnets etc could have been
> prevented with a simple compiler switch? Wow! That's awesome, Rod.
> Man, you really are a freaking genius dude! Why didn't you say
> something decades ago? I tell you what, we have a pretty much direct
> line to Microsoft here, we pay 'em thousands a year for high-priority
> support. I'll just go give 'em a call and tell them that all their
> problems are solved, for Rod Pemberton (all hail) knows the secret
> solution, the secret missing ingredient that will fix all their bugs
> overnight.
>
> But first.... I'm going to go and buy some Microsoft shares on the
> NYSE, because believe me man, this is going to be big big news.
>
> In fact, while I'm at it, I seem to recall that Cisco have their fair
> share of hassle from un-checked array access in their code, so I'll go
> give them a call too - after I've picked up some shares...
>
> [ 15 minutes later, and $10,000 dollars invested ]
>
> "Hey, is that Microsoft? Rod Pemberton told me all you have to do is
> enable bounds checking on your compilers, and then all your software
> will work!"
>
> "You're kidding, right? Is this a joke?"
>
> "I know, I know! Bloody *amazing* isn't it. Who would have thought it?
> I picked up some shares today. When are you going to do a press
> release? Don't forget to credit Pemberton, and pass his name onto
> Steve Ballmer, you could do with hiring someone like him. He's
> freaking smart man!"
>
> "Dude, say off the computer when you're high, okay?"
>
> <click>
>
> "Hello? Hello?"
>
> Hmmm... Seems they weren't too impressed with your theory Rod. But
> hey, I tried my best. I'll sit on the shares for a while, though I
> don't hold out much hope of turning a profit. The Microsoft Surface
> thing isn't going too well...
>
>>> 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.
>>
>> That's untrue.  You've made a few assumptions and taken them
>> as truth.  The first is that the bug is triggered at runtime so it
>> can be caught.
>
> Well, if an array was illegally accessed at run-time, then it *would*
> be caught, wouldn't it? At what other point *can* an array be
> illegally accessed? During compile time? While writing the source?
> Perhaps it's when I'm thinking about the problem on the train, or on
> the toilet?
>
>
>> It might not be triggered for a decade or
>> ever.
>
> Okay. But if it *is* triggered after a decade, then it would be at run-
> time, wouldn't it?
>
>> The second is that the bug is serious enough that it needs
>> to be fixed or caught.  It might not be.  Some other undectable
>> bug might be what's actually important.
>
> Please cite an example of a bug that is undetectable. Wow. I'm really
> learning a lot here. Glad I logged on. No, really.
>
>> In some other cases, a
>> bug, intentional or not, may be required for proper operation of
>> the code.
>
> -------------------------------------------------
>
> ** EXTRA EXTRA - READ ALL ABOUT IT **
> PROGRAMMER CLAIMS BUGS ARE NEEDED
> In some cases, intentional bugs are required for the correct operation
> of code, Rod Pemberton, a computer programming expert from America
> claimed today. In an inocuous, though revalatory post on Usenet,
> Pemberton claimed that in some cases, intentionally flawed code may
> actually be necessary to ensure that a software-based system runs
> correctly.
>
> The claim has raised interest and controversy in equal measure in
> programming circles. Microsoft, when approached for a comment today
> were somewhat sceptical. A spokesman for the Redmond based company
> said: "Well, we've been writing buggy code for decades, and to be
> honest, I don't think it's really helped us a whole lot. In fact, we
> employ entire departments just to conduct code quality reviews. I
> guess you could argue that bad code is good for the economy, since it
> keeps people employed, but to be honest, if you really pushed us, I
> think we'd have to say that we'd really prefer it if our code, you
> know, just worked."
>
> Boeing were more philosophical however. When approached for comment, a
> spokesman said "Gee, that's really interesting. We employ three teams
> of private third-party contractors, working independently to come up
> with triple-redundant systems for things like our flight control
> systems. I have to say, it costs us millions upon millions of dollars
> to get these software systems right, but you know, we still have the
> occasional glitch that we just can't understand. So this Pemberton guy
> is saying just, you know, sprinkle the occasional bug in there and
> it'll fix it. Hmmm... This could save us millions a year. Do you have
> this guys 'phone number?"
>
> Rod Pemberton was unavailable for comment as this article went to
> press.
>
> -------------------------------------------------
>
>
>> The third is that the VM you're using is capable of
>> detecting such an error.
>
> Oh yes of course. Because both the Java and .Net VMs cannot detect
> such an error. Nor can the Allen Bradley, Siemens, ABB and Omron VMs
> that run their 61131 code.
>
> Can you cite an example of a VM that can't detect such an error? I
> just cited six that can.
>
> Do you think that, gee, you know, just perhaps the *entire point* of
> running code on a VM is so that you *can* trap errors that a native
> piece of silicon cannot trap?
>
>> It might be.  It might not be.
>> Hopefully, it is.  However, a blanket statement that all VMs are
>> capable of catching such errors is ludicrous.
>
> I don't think it's any more ludicrous than saying that they can't.
>
>> Most VMs aren't
>> designed for security.  Most are designed for executing a
>> language.
>
> Oh dear. I don't know why I'm bothering. They do *not* execute a
> language. They execute compiled code. For Christ sakes, the .Net VM is
> *langauge independent* you idiot. In .Net you can write your code in
> C#, VB, F#, ASP, and J#.
>
> "Common Language Runtime engine
> The Common Language Runtime (CLR) serves as the execution engine of
> the .NET Framework. All .NET programs execute under the supervision of
> the CLR, guaranteeing certain properties and behaviors in the areas of
> memory management, security, and exception handling."
>
> http://en.wikipedia.org/wiki/.NET_Framework
>
> Note that last sentence, Rod: "guaranteeing certain properties and
> behaviors in the areas of memory management, security, and exception
> handling."
>
> Wow! Who'da thunk it? Hugh? Bloody clever what you can do these days,
> isn't it?
>
>> If they are designed for anything else, it's typically
>> for speed, not security.
>>
>
> But in an earlier statement above, you said:<drum roll please...>
>
> "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. "
>
> Hmmm... *Always* be slower you said. Then you say "If they are
> designed for anything else, it's typically for speed, not security."
>
> You also said:
>
> "So, whenever someone
> implements a VM nowadays, it's frequently for a single
> microprocessor target.  What's the point of that?  Slow code?
> Sand-box?  Native code can be sand-boxed too."
>
> Slow code? Did you say slow code? But just above you said:
>
> "If they are designed for anything else, it's typically
> for speed, not security."
>
> So which is it? Slow code or fast code? Pick one.
>
> Do you have any idea just how much of an ill-informed bullshit
> spouting idiot you are looking right now? I would caution you against
> making statements about subjects upon which you are ill informed. You
> know all this UseNet stuff is essentially archived forever, right? I
> would hate for you to be asked to justify your comments on this
> subject in a job interview, when presented with a print-out of this
> thread. That might be a "make my excuses and leave" moment right
> there...
>
>>> To posit that "there is no *real* point" to a VM
>>> is somewhat naive, unless you're trolling.
>>
>> No, your statement is trolling.  You know full well that there are
>> numerous processors that implement everything you mentioned and
>> everything you desire in terms of security in hardware.
>
> No I don't. Really I don't. I know of processors that can segregate
> memory space between different *processes* or tasks. I know of earlier
> mini-computer type processors that implement ring-based security that
> can prevent a crashed process from crashing other processes, but
> that's process segregation. I know of no processor that can (for
> example) within a process detect an out of bounds array access,
> because I know of no processor that has a concept of an array, much
> less a typed array. VMs, on the other hand, do. That's why they're
> used, because the underlying processor doesn't have a particular
> facility.
>
>
>> It's just
>> an issue of money.  If tens of millions of dollars are at stake as
>> claimed, then maybe the company that employs you should consider
>> such a processor, or a better class of machine, etc.  If one bug
>> could cost your company say $5 million USD, then that or twice
>> that should be the range of machine you're using.
>
> There's no need. We already have working systems, based on VMs. They
> are manufactured by companies such as Allen Bradley, who are a fortune
> 500 company, if I'm not mistaken. So thanks for the advice, but I
> think we'll just keep buying the stuff from the folks that have proven
> that they know what they're doing.
>>
>>> There's a point to JIT too, [...]
>>
>> Inefficiency?  Laziness?  Redistribution of work? costs?
>>
>
> Well, given that you said above that VMs are implemented for
> performance reasons, I find your inefficiency claim somewhat
> contradictory.
>
>
>>> 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.
>>
>> That's like claiming a compressed executable which must be
>> decompressed prior to execution starts up faster too...
>
> Excuse me? Are you on psychotropics buy any chance? No wait a minute,
> perhaps it's bath salts. Yep. Bath salts. You're clearly
> hallucinating. In what way is de-compression of pre-compiled
> executable code comparable to byte-code for use by a VM? Please
> elucidate.
>
>> How can
>> more work needing to be done before the code can execute be faster
>> somehow?
>>
>
> I said "start up much much much faster". Note the words "start" and
> "up". Please re-read.
>
>> A JIT compiler must compile every bit of code that gets executed
>> just prior to execution.  This incremental compilation is called
>> slowness.
>
> As opposed to the "speed" that you cited earlier. You've contradicted
> yourself so many times in the same post that I don't if I'm coming or
> going. This alludes to my bath salts suspicion. Have you seen the film
> Sybil, starring Sally Field?
>
>
>> Also, that code isn't saved.  If I go to a website and
>> use some part of a JIT application, the code I used gets compiled,
>> on that day.  If I go back to the same website the next day and
>> use the same part of a JIT application, the same code I used gets
>> compiled again on the next day.  Next day, same thing, over and
>> over again.  What's the point in that?
>
> Wrong wrong wrong wrong. That would be interpretation, not
> compilation. The clue is in the fact that the two words are actually
> different. Here: Try it. “Interpretation. Compilation”. I appreciate
> that they have “tion” in common, but trust me, they are different
> words with different meanings.
>
> The compiled code, once compiled, is cached. Don't assume because an
> internet web site is stateless that the VM is also stateless. I
> suppose you also think that the same code is compiled over and over
> again as different users log on to the web site and call up the same
> pages? You do, don't you?
>
>>
>> Personally, I think DEC's FX!32 should be considered to be the
>> "original" application of JIT.  It converted x86 binary to Alpha
>> binary.  So, technically, it was a binary-to-binary translator,
>> not JIT.
>> Also, it was combined with a peephole binary instruction
>> optimizer.
>> But, the effects experienced by the user are
>> essentially the same for FX!32 as for JIT.  Slowness, followed by
>> an increase in speed, if the same code that was translated and
>> optimized is used again, or more slowness if new code must be
>> translated and optimized.
>
> That's certainly true, but that does seem to be improving - though I
> concede that that might simply be down to faster CPUs rather than
> improvements in JIT technology.
>
>> The incremental translation and
>> optimization at runtime is what caused users to experience
>> slowness.
>
> True. You said something that makes sense. I congratulate you. I do
> concede that in something like an arcade game, that would be
> unacceptable; different horses for different courses. In a word
> processor you probably wouldn't notice too much - a drop down menu
> might take a little longer to open on the first click, but it's not
> the end of the world. The spell check loop might execute at 50% speed
> for the lookup of the first word, but near-native speed after that.
>
> In other uses, such as process control, it's not so much of an issue.
> If you are controlling the temperature of an oven with a PID loop and
> your integral function takes too long to execute on the first
> invocation, it's not going to make any difference at all. If you're
> looking for the Higgs Boson, then yeah, you might want to rethink.
>
>> JIT does the exact same thing.  Actually, the effects
>> of FX!32 are probably far better than JIT, since the translated
>> and optimized code for the DEC was saved and re-used, not flushed
>> like in a browser for a JIT application.
>
> Unsubstantiated drivel, as evidenced by your use of the word
> "probably". You're just spouting a stream-of-conciousness drivel,
> aren't you?
>
> Compiled code is not flushed in web applications either. It's costly
> to compile it, so why would you throw it away? You're simply
> incorrect. Simple as that. Just because a web server is stateless and
> is essentially idle when not serving pages does *not* mean that the
> underlying compiled code is dropped with each serving of a page. Do
> you not think that that simple optimization - that of compiling code
> only once - might just have possibly occurred in the minds of the
> people that were developing the technology in the first place? I mean,
> you're good Rod, but hey, let's give someone else some credit too.

Mark,

I think you let Rod get under your skin.  Maybe it's time to step back 
and just let Rod have the last, incorrect word?

Rick

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

#19161

rickman <gnuarm@gmail.com> wrote:
 
[ Gross quoting deleted ]

> I think you let Rod get under your skin.  Maybe it's time to step back 
> and just let Rod have the last, incorrect word?

It matters, it always matters, to name rubbish as rubbish ... to do
otherwise is to legitimize it. 
   -- Salman Rushdie

Andrew.

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

#19164

On Jan 26, 9:05 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> rickman <gnu...@gmail.com> wrote:
>
> [ Gross quoting deleted ]
>
> > I think you let Rod get under your skin.  Maybe it's time to step back
> > and just let Rod have the last, incorrect word?
>
> It matters, it always matters, to name rubbish as rubbish ... to do
> otherwise is to legitimize it.
>    -- Salman Rushdie
>
> Andrew.

Ah, that it might make a difference. It won't though; this is usenet.

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

#19168

On Jan 26, 12:38 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Jan 26, 9:05 am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>
> > rickman <gnu...@gmail.com> wrote:
>
> > [ Gross quoting deleted ]
>
> > > I think you let Rod get under your skin.  Maybe it's time to step back
> > > and just let Rod have the last, incorrect word?
>
> > It matters, it always matters, to name rubbish as rubbish ... to do
> > otherwise is to legitimize it.
> >    -- Salman Rushdie
>
> > Andrew.
>
> Ah, that it might make a difference. It won't though; this is usenet.

Ha! LOL!

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

#19173

Alex McDonald <blog@rivadpm.com> wrote:
> On Jan 26, 9:05?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> rickman <gnu...@gmail.com> wrote:
>>
>> [ Gross quoting deleted ]
>>
>> > I think you let Rod get under your skin. ?Maybe it's time to step back
>> > and just let Rod have the last, incorrect word?
>>
>> It matters, it always matters, to name rubbish as rubbish ... to do
>> otherwise is to legitimize it.
>>  -- Salman Rushdie
> 
> Ah, that it might make a difference. It won't though; this is usenet.

Oh, OK.  You got me there.  :-)

Andrew.

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

#19178

On 1/26/2013 2:13 PM, Andrew Haley wrote:
> Alex McDonald<blog@rivadpm.com>  wrote:
>> On Jan 26, 9:05?am, Andrew Haley<andre...@littlepinkcloud.invalid>
>> wrote:
>>> rickman<gnu...@gmail.com>  wrote:
>>>
>>> [ Gross quoting deleted ]
>>>
>>>> I think you let Rod get under your skin. ?Maybe it's time to step back
>>>> and just let Rod have the last, incorrect word?
>>>
>>> It matters, it always matters, to name rubbish as rubbish ... to do
>>> otherwise is to legitimize it.
>>>   -- Salman Rushdie
>>
>> Ah, that it might make a difference. It won't though; this is usenet.
>
> Oh, OK.  You got me there.  :-)
>
> Andrew.

Another way to put it that i prefer, "Forget it Jake.  It's Usenet".

Rick

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

#19179

rickman <gnuarm@gmail.com> writes:
> Another way to put it that i prefer, "Forget it Jake.  It's Usenet".

Not terribly PC, but this came to mind:

    http://www.reallybored.net/pictures/Arguing-on-the-Internet-is-Like

Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

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

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

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

csiph-web