>m-coughlin wrote:

>> Elizabeth D Rather wrote:

>...

>> There is something to be learned from Werty's postings. Take
>> a look at this sample (it looks better after fixing the line lengths).
>>

>>> werty wrote:

>>> Most will not have a built in assembler** . You cant work
>>> that way. You must compile it into the Dictionary.

>>

>
> The need for a Forth assembler is limited, and neither Coughlin nor
> werty has explained where it is needed for.
> (And yes assembly programming is a hobby of mine.)
>
> - Speed freaks are better served by optimising compilers.
> - If you want to use special abilities, e.g. access individual bits on
> a 8051, you bet that your forth implementor has made this available to
> you in the form of library routines.
>
> If I may take linux as an example, you may want to use assembly
> for some inherently non-portable things:
> 1. To access ports
> 2. To access the operatings system
> 3. To harness special facilities of the processor, e.g.
> the 64 bit clock counter on the Pentium
>
> Certainly the first two points are taken care of in any decent ...

> The need for a Forth assembler is limited, and neither
> Coughlin nor werty has explained where it is needed for.
> (And yes assembly programming is a hobby of mine.)

>
> m-coughlin wrote:

>> John Doty wrote:

>>>

>>>> A Forth system should compile itself by itself.

>>> Why? From an application perspective this seems an irrelevant
>>> requirement. I'd never have found the time to get LSE64 off
>>> the ground if I'd had to start with assembly. But starting
>>> with primitives and a partial compiler in C, it was easy to
>>> portably implement the rest.
>>>
>>> And LSE64 is getting jobs done. Most recently, code in LSE64
>>> has been testing a 6000 transistor mixed-signal custom VLSI
>>> chip. My first VLSI design, and it works, yee-hah!

> [snip]
> It's pretty straightforward C, I think.
>

>> If so, where can I find
>> the technical documentation? ...

> I've always considered Forth systems written in C to be code
> for a "C processor" instead of code for some particular CPU.

> Since my main interest is in Forth programming right down to the
> bare metal, and since this is much harder to do than it used to
> be, I have never even done anything with C based Forth except to
> see that it was around in many different forms. So, for a Forth
> system running without a big operating system close to the bare
> metal, is writing anything in C instead of a Forth+assembler of
> any benefit?

>
> m-coughlin wrote:
>

>>>> If so, where can I find
>>>> the technical documentation?

>>> Right now it's at
>>> http://space.mit.edu/home/jpd/lse64-0.3.tar.gz. GPL
>>> source with a brief HTML tutorial and a concise reference
>>> manual. Soon to move to www.noqsi.com.
>>>
>>> The majority of the applications I've done with it use it to
>>> operate PCI DAQ cards for electronics R&D activities.

> _____
> I wanted to try out LSE64. Downloaded package lse64-0.3.tar.gz,
> untared, configured and installed it on OpenBSD 3.9. When i
> ran the executable, it immediately caused a segmentation fault,
> and created a memory dump. I have to assume that LSE64 must be
> run under a Linux variant with kernel 2.4+? I have a copy of
> Red Hat 9.2 somewhere. ...

>
> m-coughlin wrote:

>> I've always considered Forth systems written in C to be
>> code for a "C processor" instead of code for some particular
>> CPU.

> In what sense? Nearly every C compiler generates native code.

>> Since my main interest is in Forth programming right down
>> to the bare metal, and since this is much harder to do than
>> it used to be, I have never even done anything with C based
>> Forth except...