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

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

well formed flag ?

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

Contents

  well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 15:59 +0100
    Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 16:03 +0100
      Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 08:33 -0700
        Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 09:06 -0700
          Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 09:26 -0700
            Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 20:33 +0100
              Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 20:38 +0100
              Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 12:52 -0700
                Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 21:01 +0100
                  Re: well formed flag ? Coos Haak <chforth@hccnet.nl> - 2012-10-27 22:18 +0200
                  Re: well formed flag ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-28 04:19 -0400
          Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 17:44 +0100
            Re: well formed flag ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-27 14:52 -0400
              Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 20:06 +0100
          Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 19:25 +0100
            Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 19:33 +0100
            Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-27 15:08 -0700
              Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-28 00:53 +0100
    Re: well formed flag ? Mark Wills <forthfreak@gmail.com> - 2012-10-27 09:31 -0700
      Re: well formed flag ? "A. K." <akk@nospam.org> - 2012-10-27 19:21 +0200
        Re: well formed flag ? Mark Wills <forthfreak@gmail.com> - 2012-10-27 10:33 -0700
          Re: well formed flag ? Coos Haak <chforth@hccnet.nl> - 2012-10-27 22:21 +0200
          Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-28 12:33 +1100
            Re: well formed flag ? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-27 15:46 -1000
    Re: well formed flag ? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-27 08:54 -1000
      Re: well formed flag ? Chris Hinsley <chris.hinsley@gmail.com> - 2012-10-27 20:11 +0100
    Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-28 11:05 +1100
      Re: well formed flag ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-28 11:53 +0000
        Re: well formed flag ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 14:17 +0100
          Re: well formed flag ? mhx@iae.nl (Marcel Hendrix) - 2012-10-28 16:59 +0200
            Re: well formed flag ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-28 18:37 +0100
          Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-29 23:46 +1100
            Re: well formed flag ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-29 08:33 -0500
              Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-29 08:25 -0700
                Re: well formed flag ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-29 12:27 -0500
                  Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-30 08:18 -0700
                    Re: well formed flag ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 10:33 -0500
                      Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-30 08:48 -0700
                        Re: well formed flag ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-30 11:45 -0500
                    Re: well formed flag ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-30 20:10 +0100
                      Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-10-30 15:10 -0700
                        Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-30 18:28 -0700
                          Re: well formed flag ? Alex McDonald <blog@rivadpm.com> - 2012-11-02 05:28 -0700
                            Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 08:13 -0700
                      Re: well formed flag ? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-30 12:50 -1000
                      Re: well formed flag ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-31 14:57 +0000
                        Re: well formed flag ? Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-31 17:58 +0100
                          Re: well formed flag ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-31 17:39 +0000
                        Re: well formed flag ? David Thompson <dave.thompson2@verizon.net> - 2012-11-16 23:21 -0500
                    Aliasing (was: well formed flag ?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-31 14:03 +0000
                    Re: well formed flag ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 12:06 -0400
                      Re: well formed flag ? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 09:31 -0700
                        Aliases (was: well formed flag ?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-31 17:02 +0000
                        Re: well formed flag ? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 20:06 -0400
        Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-29 23:47 +1100
          Re: well formed flag ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-30 18:02 +0000
            Re: well formed flag ? "Ed" <invalid@nospam.com> - 2012-10-31 11:44 +1100
              Re: well formed flag ? stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-31 09:25 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#16845

On Oct 30, 8:10 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Paul Rubin wrote:
> > There are a bunch of rules in C about when the compiler can assume
> > variables aren't aliased.  I don't think Forth has anything like that.
>
> Standard Forth has IMHO 6 separate memory areas:
>
> * dictionary + heap
> * code memory
> * data stack
> * return stack
> * floating point stack
> * locals
>
> You can only address the dictionary and heap with @ and !.
>
> In any case, it would be *much* better for an optimizer if you
> deliberately and explicitely can specify unaliased variables if it can
> help the compiler.

DEFER causes an aliasing problem. Beyond DEFER, I don't think there
are any other cases.

>
> Languages without arbitrary pointers like traditional Fortran have much
> stricter rules for unaliased memories.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

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

#16852

Alex McDonald <blog@rivadpm.com> writes:
> DEFER causes an aliasing problem. Beyond DEFER, I don't think there
> are any other cases.

variable x
variable y    x y !   \ y points at x
3 y @ !               \ sets x to 3

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

#16974

On Oct 31, 1:28 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Alex McDonald <b...@rivadpm.com> writes:
> > DEFER causes an aliasing problem. Beyond DEFER, I don't think there
> > are any other cases.
>
> variable x
> variable y    x y !   \ y points at x
> 3 y @ !               \ sets x to 3

Y is not an alias of X, it's a pointer to X.

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

#16976

Alex McDonald <blog@rivadpm.com> writes:
> Y is not an alias of X, it's a pointer to X.

y @ is an alias of x.

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

#16847

On 10/30/12 9:10 AM, Bernd Paysan wrote:
> Paul Rubin wrote:
>> There are a bunch of rules in C about when the compiler can assume
>> variables aren't aliased.  I don't think Forth has anything like that.
>
> Standard Forth has IMHO 6 separate memory areas:
>
> * dictionary + heap
> * code memory

The correct ANS terminology for those to is "data space" and "code 
space". Data space is accessible to user programs. The "dictionary" is 
in two parts, "name space" (headers, etc.) and "code space" (regardless 
of whether they're in the same address space). Neither name space nor 
code space guaranteed accessible to user programs.

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]

#16864

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Languages without arbitrary pointers like traditional Fortran have much 
>stricter rules for unaliased memories.

Fortran has one particular such rule: The compiler may pass parameters
by reference, but a program must not pass the same array to a
functioon through two parameters.

That rule is not present in other languages without arbitrary
pointers, such as Algol, Pascal or Java.  In particular, Jensen's
Device (Algol 60) relies on two parameters referencing the same
variable through name calling.

Conversely, one can have a rule like the Fortran rule in a language
with arbitrary pointers like Forth, or add arbitrary pointers to
Fortran.  The generalization of Fortrans parameter rule would be: two
parameters would not be allowed to point to the same contiguous region
(in Forth terminology).  I think that it would be a bad idea to add
such a rule to Forth, though, even if we would not have to care about
backwards compatibility.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#16883

Anton Ertl wrote:
> Conversely, one can have a rule like the Fortran rule in a language
> with arbitrary pointers like Forth, or add arbitrary pointers to
> Fortran.  The generalization of Fortrans parameter rule would be: two
> parameters would not be allowed to point to the same contiguous region
> (in Forth terminology).  I think that it would be a bad idea to add
> such a rule to Forth, though, even if we would not have to care about
> backwards compatibility.

Usually, applying the same parameter twice to a Fortran function, even 
when the function would be compiled in a way that it treats aliasing 
well, doesn't make much sense.  And so it would in a comparable Forth 
function.  E.g.

: matmul ( a b c -- )
\ matrix multiply a x b, store in matrix c

What would you expect as result if you use this to, let's say, rotate 
Matrix A by 90°, stored in place?

a (( ((  0 1 ))
     (( -1 0 )) )) a matmul

It quite likely will not give what you wanted, aliasing considered or 
not.  So a programmer rather would declare

: matmul ( a b -- c )
\ matrix multiply a x b, result is newly allocated matrix c

The possible aliasing between a an b is no problem, you can say "Ok, I 
want a 180° rotation, let's use the 90°, dup it and matmul it with 
itself".

(( ((  0 1 ))
   (( -1 0 )) )) dup matmul

Should work.

The rule I would add to the compiler to optimize for such cases is that 
"no pointer resulting from allocate is an alias to any pointer that 
already existed, or to any other pointer that was returned by another 
allocate".  Then the compiler knows that it can reoder the read accesses 
into the matrix multiplication as it likes, and e.g. use cache-sized 
chunks of the matrix or apply recursive divided "fast" matrix 
multiplications, which have a slightly lower O than O(n³).

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

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

#16888

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Usually, applying the same parameter twice to a Fortran function, even 
>when the function would be compiled in a way that it treats aliasing 
>well, doesn't make much sense.  And so it would in a comparable Forth 
>function.  E.g.
>
>: matmul ( a b c -- )
>\ matrix multiply a x b, store in matrix c
>
>What would you expect as result if you use this to, let's say, rotate 
>Matrix A by 90°, stored in place?
>
>a (( ((  0 1 ))
>     (( -1 0 )) )) a matmul

Ideally the rotated matrix.  But yes, in a typical implementation that
passes parameters by reference this will not work.

OTOH, if you do, say, 

a a c matmul

the Fortran equivalent would be non-standard, and the gcc maintainers
would feel encouraged to miscompile it.

In any case, from what I read, there are cases where people passed the
same parameter twice to Fortran function, and got problems on some
compilers.

>The rule I would add to the compiler to optimize for such cases is that 
>"no pointer resulting from allocate is an alias to any pointer that 
>already existed, or to any other pointer that was returned by another 
>allocate".

Yes, that's what the standard says; and I also think that programs
actually comply with this (instead of using knowledge about the
internals to go beyond the memory coming from an ALLOCATE).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#17340

On Wed, 31 Oct 2012 14:57:54 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
> >Languages without arbitrary pointers like traditional Fortran have much 
> >stricter rules for unaliased memories.
> 
> Fortran has one particular such rule: The compiler may pass parameters
> by reference, but a program must not pass the same array to a
> functioon through two parameters.
> 
Not quite. A compiler may pass by reference or by copy, and a program
must not depend on which. This means if the same actual is used for
multiple parameters (in Fortran terminology dummy arguments), OR a
parameter and also accessed by shared COMMON since forever or shared
MODULE or 'host-association' since F90; AND you write one path and
read another, it's not safe. You can have multiple paths as long as
there are no writes to any of them; or all writes and reads use one
path (but in that case why did you bother with the other paths?).

If you use certain newer features, they override. If you use POINTER
it requires by-reference and aliasing works, and may reduce
optimization accordingly. If you use VALUE it requires by-value.

> That rule is not present in other languages without arbitrary
> pointers, such as Algol, Pascal or Java.  In particular, Jensen's
> Device (Algol 60) relies on two parameters referencing the same
> variable through name calling.
> 
And COBOL, FWIW. Java (at least the standard JVM implementation of
Java) doesn't even have a mechanism to do class objects by-copy; it
must alias. Pascal does have arbitrary (but typesafe) pointers *in
addition to* by-reference VAR parameters: new(p) dispose(p) p^ .

> Conversely, one can have a rule like the Fortran rule in a language
> with arbitrary pointers like Forth, or add arbitrary pointers to
> Fortran.  The generalization of Fortrans parameter rule would be: two
> parameters would not be allowed to point to the same contiguous region
> (in Forth terminology).  I think that it would be a bad idea to add
> such a rule to Forth, though, even if we would not have to care about
> backwards compatibility.
> 
> - anton

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

#16863 — Aliasing (was: well formed flag ?)

Paul Rubin <no.email@nospam.invalid> writes:
>There are a bunch of rules in C about when the compiler can assume
>variables aren't aliased.  I don't think Forth has anything like that.

Wrong: If we applied the same attitude as seems to be dominating among
C compiler writers (that miscompiling non-standard programs is ok or
even encouraged), there is no aliasing beween the memory accesses in
the sequence "F! ! c@".  And something like that is pretty much all
that a C compiler can assume, too, even with the attitude above.
Fortunately the Forth implementors are saner and don't have that
attitude; or maybe they would be just as insane, if limits on compile
time and compiler writer time did not prevent them from implementing
optimizations that would profit from knowledge about non-aliasing.

If you are thinking of the keyword "restrict" in C, that is hardly
used.  One might introduce such a feature in Forth, too, but currently
systems would not do anything with it, and even if they did, would
programmers use it?  Judging from the C experience, most probably
would not.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#16873

"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:7xhapcgf8f.fsf@ruckus.brouhaha.com...
...

> There are a bunch of rules in C about when the compiler can assume
> variables aren't aliased.  I don't think Forth has anything like that.

After Anton pointed it out, I have to ask what you're talking about too.

Except for 'restrict' keyword, a pointer may point to or within any C
object, i.e., aliased.  Or, a pointer may point to a special location
referred to as NULL.  NULL is typically zero but not required to be.
NULL just needs to be a location where no valid C object can be located.
A pointer can usually point to non-C objects too.  While that's usually a
standard C feature, it's implementation specific according to the
specifications.


Rod Pemberton

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

#16880

"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
> Except for 'restrict' keyword, a pointer may point to or within any C
> object, i.e., aliased.

I thought the compiler could assume that (e.g.) local variables were
unaliased, unless the code actually took the address.  E.g., if you say

    int x = 3;
    foo();
    print(x);

I have the impression the compiler is allowed to constant-propagate x,
giving

    foo();
    print(3);

obviously this is not allowed if you do something with &x that might
change the value of x.

To prevent the propagation from happening (among other uses), the
"volatile" keyword was introduced.

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

#16885 — Aliases (was: well formed flag ?)

Paul Rubin <no.email@nospam.invalid> writes:
>I thought the compiler could assume that (e.g.) local variables were
>unaliased, unless the code actually took the address.  E.g., if you say
>
>    int x = 3;
>    foo();
>    print(x);
>
>I have the impression the compiler is allowed to constant-propagate x,
>giving
>
>    foo();
>    print(3);

There is no memory involved here, so no pointers that might be
aliased.  If you do the equivalent in Forth:

3 { x }
foo
x print

there is no memory or aliasing, either.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#16918

"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:7xy5imk3hp.fsf@ruckus.brouhaha.com...
> "Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
...

> > Except for 'restrict' keyword, a pointer may point to or within any C
> > object, i.e., aliased.
>
> I thought the compiler could assume that (e.g.) local variables were
> unaliased, unless the code actually took the address.  E.g., if you say
>
>     int x = 3;
>     foo();
>     print(x);
>
> I have the impression the compiler is allowed to constant-propagate x,
> giving
>
>     foo();
>     print(3);
>
...

> obviously this is not allowed if you do something with &x that might
> change the value of x.

     int x = 3;
     int *y;

     printf("%d\n",x);
     y=&x;
     *y=5;
     printf("%d\n",x);

This prints 3 and 5 here ...  Of course, the contents of 'x' is being
fetched in order to display it, due to the string conversion.  Yes?

Odd ...  I don't know if C can actually print or display a value without
going through a string conversion.  I don't believe that there is a way.  At
the moment, I can't recall any method to do so, if there is ...  I think
that the ability to directly display an integer would be required in order
to do a constant-propagation to a print-like statement that you've
demonstrated.

So, the question becomes how do you detect if a constant has been propagated
or is being fetched for display?  Any internal reference to 'x' in order to
check it's value would be detected by the compiler and might change the code
accordingly.  So, this would require something outside the C context to
modify the contents of the 'x' variable.  Of course, that something needs to
"know" exactly where to store the value.  That leads into the problem of how
do you do know the location without referencing 'x' in a way that the C
compiler or linker can detect the reference, in order to not affect the
outcome ...

> To prevent the propagation from happening (among other uses), the
> "volatile" keyword was introduced.

Well, I'm not familiar with that, or perhaps forgot it ...  A few years
back, I familiarized myself with "restrict".  I know there were some changes
made for implementing "restrict", but I don't recall what they were.  Maybe,
it's related to those changes.  I don't use "restrict", keeping mostly to
ANSI C.

AIUI, the "volatile" keyword is to indicate that a variable's value can be
modified by something outside the C context.  This prevents optimizing away
the read or write of a variables' value from or to memory, e.g., by holding
the value in a register.  E.g., it can be used to ensure reading/writing of
correct values from memory mapped I/O devices, e.g., screen, accessing
values passed from assembly routines, e.g., interrupts, etc.


Rod Pemberton

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

#16824

Stephen Pelc wrote:
> On Sun, 28 Oct 2012 11:05:55 +1100, "Ed" <invalid@nospam.com> wrote:
>
> >The downside is that a good forth optimizer isn't cheap.  IIRC Stephen
> >once quoted a figure of 50,000 lines of code.
>
> Aout 5,000 lines for many CPUs. 6,000 lines for the x86 version.
> Then add the code for the assembler and disassembler.

No doubt you're glad it's not 50,000 :)

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

#16843

On Mon, 29 Oct 2012 23:47:23 +1100, "Ed" <invalid@nospam.com> wrote:

>Stephen Pelc wrote:
>> On Sun, 28 Oct 2012 11:05:55 +1100, "Ed" <invalid@nospam.com> wrote:
>>
>> >The downside is that a good forth optimizer isn't cheap.  IIRC Stephen
>> >once quoted a figure of 50,000 lines of code.
>>
>> Aout 5,000 lines for many CPUs. 6,000 lines for the x86 version.
>> Then add the code for the assembler and disassembler.
>
>No doubt you're glad it's not 50,000 :)

Oh, yes.

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]

#16850

Stephen Pelc wrote:
> On Mon, 29 Oct 2012 23:47:23 +1100, "Ed" <invalid@nospam.com> wrote:
>
> >Stephen Pelc wrote:
> >> On Sun, 28 Oct 2012 11:05:55 +1100, "Ed" <invalid@nospam.com> wrote:
> >>
> >> >The downside is that a good forth optimizer isn't cheap.  IIRC Stephen
> >> >once quoted a figure of 50,000 lines of code.
> >>
> >> Aout 5,000 lines for many CPUs. 6,000 lines for the x86 version.
> >> Then add the code for the assembler and disassembler.
> >
> >No doubt you're glad it's not 50,000 :)
>
> Oh, yes.

You mention the disassembler.  Is this used by the code generator
in any way?

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

#16854

On Wed, 31 Oct 2012 11:44:30 +1100, "Ed" <invalid@nospam.com> wrote:

>You mention the disassembler.  Is this used by the code generator
>in any way?

It's used by the humans testing the code generator.

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] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web