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

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

typical actual time for implementing kernel in a new architecture?

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

Contents

  typical actual time for implementing kernel in a new architecture? Joel Rees <joel.rees@gmail.com> - 2017-05-01 02:24 -0700
    Re: typical actual time for implementing kernel in a new architecture? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-01 17:40 +0200
      Re: typical actual time for implementing kernel in a new architecture? Ron Aaron <rambamist@gmail.com> - 2017-05-01 19:35 +0300
        Re: typical actual time for implementing kernel in a new architecture? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-02 08:13 +0200
      Re: typical actual time for implementing kernel in a new architecture? Joel Rees <joel.rees@gmail.com> - 2017-05-01 15:17 -0700
        Re: typical actual time for implementing kernel in a new architecture? hughaguilar96@gmail.com - 2017-05-01 20:11 -0700
        Re: typical actual time for implementing kernel in a new architecture? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-02 09:07 +0200
    Re: typical actual time for implementing kernel in a new architecture? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-01 18:34 -0400
    Re: typical actual time for implementing kernel in a new architecture? "Elizabeth D. Rather" <erather@forth.com> - 2017-05-01 12:41 -1000
    Re: typical actual time for implementing kernel in a new architecture? hughaguilar96@gmail.com - 2017-05-01 19:33 -0700
    Re: typical actual time for implementing kernel in a new architecture? Mark Wills <markwills1970@gmail.com> - 2017-05-02 01:51 -0700
    Re: typical actual time for implementing kernel in a new architecture? minforth@arcor.de - 2017-05-02 06:17 -0700
      Re: typical actual time for implementing kernel in a new architecture? Cecil Bayona <cbayona@cbayona.com> - 2017-05-02 12:59 -0500
        Re: typical actual time for implementing kernel in a new architecture? "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 10:07 -1000
          Re: typical actual time for implementing kernel in a new architecture? Cecil Bayona <cbayona@cbayona.com> - 2017-05-02 15:39 -0500
            Re: typical actual time for implementing kernel in a new architecture? minforth@arcor.de - 2017-05-02 22:29 -0700
              Re: typical actual time for implementing kernel in a new architecture? Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 01:12 -0500
                Re: typical actual time for implementing kernel in a new architecture? minforth@arcor.de - 2017-05-03 02:06 -0700
                  Re: typical actual time for implementing kernel in a new architecture? Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 13:52 -0500
                    Re: typical actual time for implementing kernel in a new architecture? minforth@arcor.de - 2017-05-03 22:23 -0700
                      Re: typical actual time for implementing kernel in a new architecture? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-05-04 04:59 -0700
      Re: typical actual time for implementing kernel in a new architecture? Rob Sciuk <rob@controlq.com> - 2017-05-08 15:38 -0400
    Re: typical actual time for implementing kernel in a new architecture? stephen@mpeforth.com (Stephen Pelc) - 2017-05-02 19:41 +0000
      Re: typical actual time for implementing kernel in a new architecture? Cecil Bayona <cbayona@cbayona.com> - 2017-05-02 15:25 -0500

Page 1 of 2  [1] 2  Next page →

#58436 — typical actual time for implementing kernel in a new architecture?

I'm just wondering how slow I am.

For those who regularly implement kernels in new CPU architectures, about how long does it take on average? And how does your current expected time compare with your first conversion time?

I guess I should mention that my first implementation, converting a fig-Forth model for the 6800 listing that I had to 6809, took three months or so, teaching myself Forth as I went. Part of that time was figuring out how to use the system I was developing on, and part of it was constructing some minor modifications for the college class I was doing the work for. (The teacher required it to be different, so that the students would not be just grabbing a model and assembling it on lab hardware.) The 6800 model was indirect threaded, I used subroutine jumps into the 6809 direct page; I used an unbalanced binary tree for the symbol table, and I did something else that was non-fig.)

My second implementation, some fifteen years later, was in C. From the time I figured out how I would construct the kernel so as not to fight with C too much but allow the kernel to function more or less as the fig model did, until the time I had maybe half of it debugged was several years, working during after work and during vacation time and such. (I was teaching myself how to use subversion as I went. Also was careful to avoid using the standard C libraries for anything but debugging printf()s.) Never did finish debugging to the point that I could properly FORGET definitions. 

Decided to convert the 6800 model to sh3 for another project I thought I could devote 200 hours to, and had half the conversion done at about 100 hours. That including learning how to coerce the sh3 assembler to allow me to construct the model run-time architecture, modifying stuff for 32 bits, testing to make sure I had the math right, and, what probably consumed about half of my time, separating the source out into functional modules, each to its own source file. 

Never got it to the point where I could bring the interpreter up because I wasn't able to finagle the final 100 hours while I had access to the target hardware.

Compiling my incompletely debugged C version on the sh-3 target running Linux was actually quite straightforward, only took an hour or so. But I've never built an assembler for the C version on any of the machines I've compiled and run it on, and didn't try to do so on that project.

Back in the mid-to-late 1980s, I read a book on implementing a generalized TIL where the author seemed to imply that the book could teach one how to implement a new TIL in twenty hours. I was never able to successfully follow the guy's approach.

If I had more experience with gforth, I probably would have focused on getting gforth to compile on the Linux environment we were using. Or, if I had more experience with a more traditional Forth-like process, I might have tried getting a cross-assembler running, writing a kernel in that, etc. But I'm not sure I could have brought the expected implementation time down under 100 hours.

Anyway, I was wondering today, for no good reason, how my 200 hours (expected) development time compares with the time that people who have more experience with such things would expect for themselves.

[toc] | [next] | [standalone]

#58444

Joel Rees wrote:
> For those who regularly implement kernels in new CPU architectures,
> about how long does it take on average?

My Forth is designed for portability, so it's quite easy to plug in
definitions for a new architecture.

If everything goes reasonably well, it takes about a day to write a new
assembler, and another day for writing the new assembly language
primitives and testing the resulting Forth image.

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

#58445

On 01/05/2017 18:40, Lars Brinkhoff wrote:

> If everything goes reasonably well, it takes about a day to write a new
> assembler, and another day for writing the new assembly language
> primitives and testing the resulting Forth image.

Really?  That's quite impressive.

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

#58468

Ron Aaron wrote:
>> If everything goes reasonably well, it takes about a day to write a
>> new assembler, and another day for writing the new assembly language
>> primitives and testing the resulting Forth image.
> Really?  That's quite impressive.

My ARM port took two days, but maybe that's a best case scenario:  A nice
architecture (just the simple original 32-bit instruction set), and lot
of copying from previous targets.

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

#58454

On Tuesday, May 2, 2017 at 12:40:08 AM UTC+9, Lars Brinkhoff wrote:
> Joel Rees wrote:
> > For those who regularly implement kernels in new CPU architectures,
> > about how long does it take on average?
> 
> My Forth is designed for portability, so it's quite easy to plug in
> definitions for a new architecture.
> 
> If everything goes reasonably well, it takes about a day to write a new
> assembler, and another day for writing the new assembly language
> primitives and testing the resulting Forth image.

[sarcasm]
So I guess, since I have no hope of ever being within an order of 
magnitude of being such a superprogrammer as you, that I should just 
go throw myself under the train and get out of your way.
[end sarcasm]

I'm not asking for a bragfest. 

I was kind of hoping for a little serious discussion on productivity 
that I might start other serious threads on methods from.

So, I assume you mean lbforth, which I see on github. 

Give me a reason to actually spend a day cloning the repository and 
playing with what you have so I can figure out whether the inner 
interpreter, for instance, is something I could work with.

Tell me a little about what you mean by "reasonably well".

Tell me what happens when things don't go reasonably well, and
what I can look for, for indications that they could go really 
badly, and just how bad things are when they go really badly.

Tell me if you need a native lisp for the target. (Only for the 
host?). And tell me if you need a running C (cross?) compiler for 
the target. (Is that gcc in cross compile?)

Maybe, since I mentioned my interest in the 6809, tell me why 
targets/README.md appears to indicate the 6809 as "research".
(It would seem to me that the 6809 should go reasonably well 
if any sixteen bit architecture should. If not, I could guess 
why, but I'd like a little more than my guesses about what
you are doing, to work from.)

And, since I'm asking, I'll ask about PowerPC. If someone were 
to pay you to get your system to produce a PowerPC target, how
long do you think it would take you to get it up? (I'm not 
offering.) What would take the bulk of your time? (I'd guess 
understanding the arcane nature of the instruction set?)

And give me an estimate about how long you have been working on 
lbforth, maybe about how many hours or man-months or years 
it took from conception to being able to metacompile the x86 
target. 

Maybe I could have framed my question better, but I'm not really 
asking about anyone's skills. I'm trying to get a handle on what 
methods are being used in the Forth community, and how effective 
the methods are.

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

#58465

On Monday, May 1, 2017 at 3:17:22 PM UTC-7, Joel Rees wrote:
> And, since I'm asking, I'll ask about PowerPC. If someone were 
> to pay you to get your system to produce a PowerPC target, how
> long do you think it would take you to get it up? (I'm not 
> offering.) What would take the bulk of your time? (I'd guess 
> understanding the arcane nature of the instruction set?)

Is it the PowerPC that you are working on? 

This is going to vary a lot, depending upon the processor. For example, a 65c02 assembler is super-simple, a Z80 assembler is several times more complicated, and a PowerPC assembler is likely several times more complicated yet.

Also, what do you mean by kernel? If this is going to include floating-point, writing all those functions can be time-consuming. Is this Forth going to run under an OS or on the bare metal? What you mean by kernel is going to vary a lot depending upon how ambitious you are for what your Forth system can do.

Another point is that there is a difference between doing a good job and a bad job. In the old days, there were multiple 6502 Forths, all of which were terrible. They used a combined stack with the high and low bytes next to each other, so a DROP required two INX instructions. The smart way to do this is to have a split stack --- one stack for high bytes and one stack for low bytes --- then a DROP is done with single INX instruction. My point is that asking how many weeks is required, is nonsense if the result is screwed up. It can take years to get good at a particular assembly-language! I'm reasonably good at 6502 assembly-language, but Michael Barry is likely better at it --- the 6502 is a very simple assembly-language, so you would think I would know everything there is to know about it, but I don't --- the difference is mostly practice; he writes 6502 asm all the time, and I haven't at all in 25 years.

I noticed that MPE recently employed Randy Dumse of R65f11 infamy. I say infamy, because the R65F11 was notoriously slow and gave Forth a bad name because of this. It used a combined stack, as I mentioned above being a bad idea. It also used ITC which is horrible on the 6502 --- it was apparently just a FIGforth port, without much thought toward doing a better job. Just today I looked at MPE's website:
http://www.mpeforth.com/sample-page/46-2/
Several of the employees, including Randy Dumse, are no longer listed. It looks like Stephen Pelc fired a lot of his people --- don't know if this is because they weren't doing their jobs, or because MPE is running out of money --- he still has Peter Knaggs, so MPE continues to have two votes on the Forth-200x committee.

> Maybe I could have framed my question better, but I'm not really 
> asking about anyone's skills. I'm trying to get a handle on what 
> methods are being used in the Forth community, and how effective 
> the methods are.

I don't have much experience with writing a Forth system for a new processor. I've never actually done it. I'm doing it now with Straight Forth, but this is not just a port of a basic Forth system --- it has a lot of features different from ANS-Forth so design is taking a while.

My only experience is with cross-compilers. I wrote a 65c02 cross-compiler that ran on the MS-DOS under UR/Forth and generated code for the Apple-IIc. This was compatible with ISYS Forth, so the kernel used quite a lot of ISYS Forth, such as the floating-point, and so I didn't have to write any of this myself. At the time, I wrote a source-level single-step debugger --- it was roughly comparable to Borland Turbo Debugger that I was familiar with --- I wouldn't do that now, but I thought it was a good idea in those days.

Later on, I got employed at Testra and wrote MFX for their MiniForth processor. My experience with the MiniForth, is that the processor instruction set changed on a daily basis. The processor was getting developed, which takes months --- it didn't exist physically until the end of the project. My assembler/simulator had to be written in such a way that frequent changes could be made in what instructions we had and what they did. The MiniForth was several times more complicated than the PowerPC because the MiniForth could pack up to 5 instructions in a single opcode and they would all execute concurrently in a single clock-cycle.

Anyway --- I can't answer your question because you haven't provided enough information.

I will say that quality is more important than speed, so asking how many weeks it takes is not the right question --- instead you should be asking how you can be better than everybody else --- there is no point in the exercise if you aren't going to be better than everybody else.

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

#58471

Joel Rees wrote:
> So I guess, since I have no hope of ever being within an order of 
> magnitude of being such a superprogrammer

Sorry, it was an honest answer.  If it makes you feel better, it took
much longer the first few times.

> So, I assume you mean lbforth, which I see on github.  Give me a
> reason to actually spend a day cloning the repository and playing with
> what you have so I can figure out whether the inner interpreter, for
> instance, is something I could work with.

It's mostly my personal plaything.  It's not made for public
consumption.

> Tell me a little about what you mean by "reasonably well".

Right, that's a key phrase.  It means that I can take an existing
target similar to the new target, and copy or modify lots of code.
And that there are no tricky bugs to work out.

> Tell me what happens when things don't go reasonably well, and
> what I can look for, for indications that they could go really 
> badly, and just how bad things are when they go really badly.

One time there was a typo in one of the assembly language primitives.
It was quite hard to fix, because there was just a crash at one
place, and the problem was entirely somewhere else.  Debugging this
is hard.  Gdb isn't much help.  The inner interpreter doesn't leave
much trace of what happened before.  There's some kind of backtrace
in the return stack, but it's hard to inspect.

> Tell me if you need a native lisp for the target. (Only for the 
> host?). And tell me if you need a running C (cross?) compiler for 
> the target.

Lisp and C are only used for bootstrapping.  Once the bootstrap Forth
(the b-forth executable) has been made, Lisp or C are no longer needed.

> Maybe, since I mentioned my interest in the 6809, tell me why 
> targets/README.md appears to indicate the 6809 as "research".

It means I have looked into the 6809 instruction set and made some
notes.  It's the first step towards making an assembler.

> And, since I'm asking, I'll ask about PowerPC. If someone were 
> to pay you to get your system to produce a PowerPC target, how
> long do you think it would take you to get it up? (I'm not 
> offering.) What would take the bulk of your time? (I'd guess 
> understanding the arcane nature of the instruction set?)

A bare-bones port to Linux would probably only take a few days.  Say a
week at the most.  I'm supposing the instruction set isn't that much
more quirky than say ARM v4.  The work would probaby be evenly split
between the assembler and the kernel.

If there were a paying customer, I'd expect them to have some
requirements that would take much more time to satisfy.

> And give me an estimate about how long you have been working on
> lbforth, maybe about how many hours or man-months or years it took
> from conception to being able to metacompile the x86 target.

Hard to say exactly since I've done it in my spare time.  Say a few
hours every week since early 2013 to late 2015.  That's about 140 weeks.
Maybe 500 hours.

> Maybe I could have framed my question better, but I'm not really 
> asking about anyone's skills. I'm trying to get a handle on what 
> methods are being used in the Forth community, and how effective 
> the methods are.

I'm not claiming to be very skilled.  It has taken me years to get to
this point, and I still have much to learn.

These time estimates probably are realistic once you learn to use Forth
effectively.  It's bread-and-butter Forth programming.

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

#58456

On Mon, 1 May 2017 02:24:38 -0700 (PDT)
Joel Rees <joel.rees@gmail.com> wrote:

> Anyway, I was wondering today, for no good reason, how my 200 hours
> (expected) development time compares with the time that people who
> have more experience with such things would expect for themselves.
> 

I developed a Forth in interpreter in C (ITC) with no prior experience
in implementing a Forth and without any Forth programming experience.  I
have no idea how many hours it has taken, but I've put in many, many
hours over many years, i.e., back to 2007 or 2005 or so.  This was
using as much info as I could get online, e.g., comp.lang.forth,
net.lang.forth, fig-Forth source, websites, pages, papers or books by
people like Philip Koopman, Leo Brodie, Brad Rodriquez, Rob Chapman,
Anton Ertl, etc.


Rod Pemberton
-- 
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.

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

#58457

On 4/30/17 11:24 PM, Joel Rees wrote:
> I'm just wondering how slow I am.
>
> For those who regularly implement kernels in new CPU architectures, about how long does it take on average? And how does your current expected time compare with your first conversion time?
>
> I guess I should mention that my first implementation, converting a fig-Forth model for the 6800 listing that I had to 6809, took three months or so, teaching myself Forth as I went. Part of that time was figuring out how to use the system I was developing on, and part of it was constructing some minor modifications for the college class I was doing the work for. (The teacher required it to be different, so that the students would not be just grabbing a model and assembling it on lab hardware.) The 6800 model was indirect threaded, I used subroutine jumps into the 6809 direct page; I used an unbalanced binary tree for the symbol table, and I did something else that was non-fig.)
>
> My second implementation, some fifteen years later, was in C. From the time I figured out how I would construct the kernel so as not to fight with C too much but allow the kernel to function more or less as the fig model did, until the time I had maybe half of it debugged was several years, working during after work and during vacation time and such. (I was teaching myself how to use subversion as I went. Also was careful to avoid using the standard C libraries for anything but debugging printf()s.) Never did finish debugging to the point that I could properly FORGET definitions.
>
> Decided to convert the 6800 model to sh3 for another project I thought I could devote 200 hours to, and had half the conversion done at about 100 hours. That including learning how to coerce the sh3 assembler to allow me to construct the model run-time architecture, modifying stuff for 32 bits, testing to make sure I had the math right, and, what probably consumed about half of my time, separating the source out into functional modules, each to its own source file.
>
> Never got it to the point where I could bring the interpreter up because I wasn't able to finagle the final 100 hours while I had access to the target hardware.
>
> Compiling my incompletely debugged C version on the sh-3 target running Linux was actually quite straightforward, only took an hour or so. But I've never built an assembler for the C version on any of the machines I've compiled and run it on, and didn't try to do so on that project.
>
> Back in the mid-to-late 1980s, I read a book on implementing a generalized TIL where the author seemed to imply that the book could teach one how to implement a new TIL in twenty hours. I was never able to successfully follow the guy's approach.
>
> If I had more experience with gforth, I probably would have focused on getting gforth to compile on the Linux environment we were using. Or, if I had more experience with a more traditional Forth-like process, I might have tried getting a cross-assembler running, writing a kernel in that, etc. But I'm not sure I could have brought the expected implementation time down under 100 hours.
>
> Anyway, I was wondering today, for no good reason, how my 200 hours (expected) development time compares with the time that people who have more experience with such things would expect for themselves.
>

When Chuck was still working at FORTH, Inc. (1973-82) he regularly took 
about two weeks to put polyFORTH on a new minicomputer CPU. This 
involved designing the implementation (e.g. register allocation), 
writing the assembler, writing the assembler routines for the target, 
writing drivers for all the I/O (disk, terminal, printer, etc.), 
figuring out how to get the program installed on the target, and getting 
all the electives working. A full compile took a few seconds (4 or 5). I 
recall one job when the only communication path to the new target was a 
2-bit line. He had to write a bootstrap to key in on the target's 
console and a driver from the host end and make that work.

With the advent of interactive cross-compilers it got somewhat easier, 
but in some cases the communication link involved proprietary info and 
could be tricky. Leon typically takes 2-4 weeks. Compiles are <1 sec.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#58463

On Monday, May 1, 2017 at 2:24:39 AM UTC-7, Joel Rees wrote:
> Back in the mid-to-late 1980s, I read a book on implementing a generalized TIL where the author seemed to imply that the book could teach one how to implement a new TIL in twenty hours. I was never able to successfully follow the guy's approach.

Was that the book, "Threaded Interpretive Languages" (R.G. Loelinger)?

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

#58479

On Monday, 1 May 2017 10:24:39 UTC+1, Joel Rees  wrote:
> I'm just wondering how slow I am.
> 
> For those who regularly implement kernels in new CPU architectures, about how long does it take on average? And how does your current expected time compare with your first conversion time?
> 
> I guess I should mention that my first implementation, converting a fig-Forth model for the 6800 listing that I had to 6809, took three months or so, teaching myself Forth as I went. Part of that time was figuring out how to use the system I was developing on, and part of it was constructing some minor modifications for the college class I was doing the work for. (The teacher required it to be different, so that the students would not be just grabbing a model and assembling it on lab hardware.) The 6800 model was indirect threaded, I used subroutine jumps into the 6809 direct page; I used an unbalanced binary tree for the symbol table, and I did something else that was non-fig.)
> 
> My second implementation, some fifteen years later, was in C. From the time I figured out how I would construct the kernel so as not to fight with C too much but allow the kernel to function more or less as the fig model did, until the time I had maybe half of it debugged was several years, working during after work and during vacation time and such. (I was teaching myself how to use subversion as I went. Also was careful to avoid using the standard C libraries for anything but debugging printf()s.) Never did finish debugging to the point that I could properly FORGET definitions. 
> 
> Decided to convert the 6800 model to sh3 for another project I thought I could devote 200 hours to, and had half the conversion done at about 100 hours. That including learning how to coerce the sh3 assembler to allow me to construct the model run-time architecture, modifying stuff for 32 bits, testing to make sure I had the math right, and, what probably consumed about half of my time, separating the source out into functional modules, each to its own source file. 
> 
> Never got it to the point where I could bring the interpreter up because I wasn't able to finagle the final 100 hours while I had access to the target hardware.
> 
> Compiling my incompletely debugged C version on the sh-3 target running Linux was actually quite straightforward, only took an hour or so. But I've never built an assembler for the C version on any of the machines I've compiled and run it on, and didn't try to do so on that project.
> 
> Back in the mid-to-late 1980s, I read a book on implementing a generalized TIL where the author seemed to imply that the book could teach one how to implement a new TIL in twenty hours. I was never able to successfully follow the guy's approach.
> 
> If I had more experience with gforth, I probably would have focused on getting gforth to compile on the Linux environment we were using. Or, if I had more experience with a more traditional Forth-like process, I might have tried getting a cross-assembler running, writing a kernel in that, etc. But I'm not sure I could have brought the expected implementation time down under 100 hours.
> 
> Anyway, I was wondering today, for no good reason, how my 200 hours (expected) development time compares with the time that people who have more experience with such things would expect for themselves.

Assuming you're writing "on the metal" (i.e. in Assembly language) and you
are familiar with the instruction set and architecture, then you should 
have a simple non-optimising Forth up in about a week at the most.

Trouble is, when are they "finished"? If my own system (TMS9900) is
anything to go by, you keep tinkering with/improving them for years
after as you have further ideas; sometimes re-writing entire sections
just to accommodate a new idea/technique. I re-wrote the DO/LOOP/+LOOP
primitives at least twice.

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

#58493

Am Montag, 1. Mai 2017 11:24:39 UTC+2 schrieb Joel Rees:
> I'm just wondering how slow I am.
> 
> For those who regularly implement kernels in new CPU architectures, about how long does it take on average? And how does your current expected time compare with your first conversion time?
> 
> I guess I should mention that my first implementation, converting a fig-Forth model for the 6800 listing that I had to 6809, took three months or so, teaching myself Forth as I went. Part of that time was figuring out how to use the system I was developing on, and part of it was constructing some minor modifications for the college class I was doing the work for. (The teacher required it to be different, so that the students would not be just grabbing a model and assembling it on lab hardware.) The 6800 model was indirect threaded, I used subroutine jumps into the 6809 direct page; I used an unbalanced binary tree for the symbol table, and I did something else that was non-fig.)
> 
> My second implementation, some fifteen years later, was in C. From the time I figured out how I would construct the kernel so as not to fight with C too much but allow the kernel to function more or less as the fig model did, until the time I had maybe half of it debugged was several years, working during after work and during vacation time and such. (I was teaching myself how to use subversion as I went. Also was careful to avoid using the standard C libraries for anything but debugging printf()s.) Never did finish debugging to the point that I could properly FORGET definitions. 
> 
> Decided to convert the 6800 model to sh3 for another project I thought I could devote 200 hours to, and had half the conversion done at about 100 hours. That including learning how to coerce the sh3 assembler to allow me to construct the model run-time architecture, modifying stuff for 32 bits, testing to make sure I had the math right, and, what probably consumed about half of my time, separating the source out into functional modules, each to its own source file. 
> 
> Never got it to the point where I could bring the interpreter up because I wasn't able to finagle the final 100 hours while I had access to the target hardware.
> 
> Compiling my incompletely debugged C version on the sh-3 target running Linux was actually quite straightforward, only took an hour or so. But I've never built an assembler for the C version on any of the machines I've compiled and run it on, and didn't try to do so on that project.
> 
> Back in the mid-to-late 1980s, I read a book on implementing a generalized TIL where the author seemed to imply that the book could teach one how to implement a new TIL in twenty hours. I was never able to successfully follow the guy's approach.
> 
> If I had more experience with gforth, I probably would have focused on getting gforth to compile on the Linux environment we were using. Or, if I had more experience with a more traditional Forth-like process, I might have tried getting a cross-assembler running, writing a kernel in that, etc. But I'm not sure I could have brought the expected implementation time down under 100 hours.
> 
> Anyway, I was wondering today, for no good reason, how my 200 hours (expected) development time compares with the time that people who have more experience with such things would expect for themselves.

As others have said: it depends on where you start from, it depends on when you consider it finished, on the target machine, and of course on your own skills and available tools. I would define that a new Forth system is finished when it passes the Hayes' core wordset test.

I have a working 32-bit system for x86 CPUs to start with, primitives defined in C, high-level words in Forth. The ARM port took about one day, with some math code adjustments that I ported back to the original system too.

But I was lucky to have gcc-arm. Things can become messy when C libraries are missing. But then one can always put in some _asm lines where needed. Other typical pitfalls are address alignment issues, memory layout, internal location of elements within structs, etc. But this is no Forth problem really, but normal engineering work.

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

#58515

On 5/2/2017 8:17 AM, minforth@arcor.de wrote:
> Am Montag, 1. Mai 2017 11:24:39 UTC+2 schrieb Joel Rees:
>> I'm just wondering how slow I am.
>>
>> For those who regularly implement kernels in new CPU architectures, about how long does it take on average? And how does your current expected time compare with your first conversion time?
>>
>> I guess I should mention that my first implementation, converting a fig-Forth model for the 6800 listing that I had to 6809, took three months or so, teaching myself Forth as I went. Part of that time was figuring out how to use the system I was developing on, and part of it was constructing some minor modifications for the college class I was doing the work for. (The teacher required it to be different, so that the students would not be just grabbing a model and assembling it on lab hardware.) The 6800 model was indirect threaded, I used subroutine jumps into the 6809 direct page; I used an unbalanced binary tree for the symbol table, and I did something else that was non-fig.)
>>
>> My second implementation, some fifteen years later, was in C. From the time I figured out how I would construct the kernel so as not to fight with C too much but allow the kernel to function more or less as the fig model did, until the time I had maybe half of it debugged was several years, working during after work and during vacation time and such. (I was teaching myself how to use subversion as I went. Also was careful to avoid using the standard C libraries for anything but debugging printf()s.) Never did finish debugging to the point that I could properly FORGET definitions.
>>
>> Decided to convert the 6800 model to sh3 for another project I thought I could devote 200 hours to, and had half the conversion done at about 100 hours. That including learning how to coerce the sh3 assembler to allow me to construct the model run-time architecture, modifying stuff for 32 bits, testing to make sure I had the math right, and, what probably consumed about half of my time, separating the source out into functional modules, each to its own source file.
>>
>> Never got it to the point where I could bring the interpreter up because I wasn't able to finagle the final 100 hours while I had access to the target hardware.
>>
>> Compiling my incompletely debugged C version on the sh-3 target running Linux was actually quite straightforward, only took an hour or so. But I've never built an assembler for the C version on any of the machines I've compiled and run it on, and didn't try to do so on that project.
>>
>> Back in the mid-to-late 1980s, I read a book on implementing a generalized TIL where the author seemed to imply that the book could teach one how to implement a new TIL in twenty hours. I was never able to successfully follow the guy's approach.
>>
>> If I had more experience with gforth, I probably would have focused on getting gforth to compile on the Linux environment we were using. Or, if I had more experience with a more traditional Forth-like process, I might have tried getting a cross-assembler running, writing a kernel in that, etc. But I'm not sure I could have brought the expected implementation time down under 100 hours.
>>
>> Anyway, I was wondering today, for no good reason, how my 200 hours (expected) development time compares with the time that people who have more experience with such things would expect for themselves.
> 
> As others have said: it depends on where you start from, it depends on when you consider it finished, on the target machine, and of course on your own skills and available tools. I would define that a new Forth system is finished when it passes the Hayes' core wordset test.
> 
> I have a working 32-bit system for x86 CPUs to start with, primitives defined in C, high-level words in Forth. The ARM port took about one day, with some math code adjustments that I ported back to the original system too.
> 
> But I was lucky to have gcc-arm. Things can become messy when C libraries are missing. But then one can always put in some _asm lines where needed. Other typical pitfalls are address alignment issues, memory layout, internal location of elements within structs, etc. But this is no Forth problem really, but normal engineering work.
> 

I'm about to start creating a Forth based on eForth using the Go 
language. I have a version that is 80% finished in C but I want to lean 
Go so it will be slowed down by the learning process.

I will be documenting the hours spent on the various phases of the 
project so I will post it here. Since I have source to other versions of 
eForth it will be basically the process to bring up eForth on another 
CPU, I expect the first go at it will take longer at it than the second 
and third time. The first version will be for Windows after than I 
expect conversion to ARM, PIC, dsPIC, PIC32, and MSP430 will follow but 
I expect them to be way faster since everything will be figured out by then.

-- 
Cecil - k5nwa

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

#58535

On 5/2/17 7:59 AM,  minforth@arcor.de wrote:
> As others have said: it depends on where you start from, it depends on
> when you consider it finished, on the target machine, and of course on
> your own skills and available tools. I would define that a new Forth
> system is finished when it passes the Hayes' core wordset test.

Good point. To clarify my contribution above, we start from a 
cross-compiler (nowadays SwiftX) with Forth source for most kernel and 
other high-level words. We optimize for performance, not porting ease. 
The most challenging steps are:

1. Designing the VM for the new target (register usage and other 
optimizations), then writing the assembler and the required primitives.

2. Working out how to run the umbilical for a seamlessly interactive 
development environment. The actual nature of the link depends on the 
target hardware. Most target hardware uses a serial line connected to an 
onboard serial port; the NXP 68332 and 68HC16 use NXP’s Background 
Debugging Mode (BDM), and communicate via a parallel port.

3. Writing the user manual for the target.

The job is done when we have a tested, documented, releasable product, 
including libraries with hundreds of routines, such as:

     * integer and fixed-point fraction arithmetic and transcendental 
functions
     * string handling
     * clock and calendar
     * number conversions
     * drivers for serial ports, clock, and other devices and many 
others, depending on the target CPU

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#58538

On 5/2/2017 3:07 PM, Elizabeth D. Rather wrote:
> On 5/2/17 7:59 AM,  minforth@arcor.de wrote:
>> As others have said: it depends on where you start from, it depends on
>> when you consider it finished, on the target machine, and of course on
>> your own skills and available tools. I would define that a new Forth
>> system is finished when it passes the Hayes' core wordset test.
> 
> Good point. To clarify my contribution above, we start from a 
> cross-compiler (nowadays SwiftX) with Forth source for most kernel and 
> other high-level words. We optimize for performance, not porting ease. 
> The most challenging steps are:
> 
> 1. Designing the VM for the new target (register usage and other 
> optimizations), then writing the assembler and the required primitives.
> 
> 2. Working out how to run the umbilical for a seamlessly interactive 
> development environment. The actual nature of the link depends on the 
> target hardware. Most target hardware uses a serial line connected to an 
> onboard serial port; the NXP 68332 and 68HC16 use NXP’s Background 
> Debugging Mode (BDM), and communicate via a parallel port.
> 
> 3. Writing the user manual for the target.
> 
> The job is done when we have a tested, documented, releasable product, 
> including libraries with hundreds of routines, such as:
> 
>      * integer and fixed-point fraction arithmetic and transcendental 
> functions
>      * string handling
>      * clock and calendar
>      * number conversions
>      * drivers for serial ports, clock, and other devices and many 
> others, depending on the target CPU
> 
> Cheers,
> Elizabeth
> 
Looking at the source code of SwiftForth I can see that is well 
organized and easy to follow, the one section that will take a little 
time studying is the optimizer.

I have worked on text based optimizers in the past and was able to 
generate extremely good code but the optimizer was very complex and not 
very fast as I would have liked, but it was extremely flexible and quite 
capable. Using a template file to control the conversion of the 
generated code. It used a Balanced Tree + to store and manipulate the 
code. Being highly recursive is what made it slower but also gave it the 
capacity to generate code that looked like a decent programmer wrote it 
by hand. A negative was that once the final code was generated it was 
difficult to link it back to the original source as the final product 
often bore no resemblance to the original code. But all of that was 
controlled by the user and how many interacting rules one had.

-- 
Cecil - k5nwa

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

#58552

Am Dienstag, 2. Mai 2017 22:39:08 UTC+2 schrieb Cecil - k5nwa:
> On 5/2/2017 3:07 PM, Elizabeth D. Rather wrote:
> > On 5/2/17 7:59 AM,  minforth@arcor.de wrote:
> >> As others have said: it depends on where you start from, it depends on
> >> when you consider it finished, on the target machine, and of course on
> >> your own skills and available tools. I would define that a new Forth
> >> system is finished when it passes the Hayes' core wordset test.
> > 
> > Good point. To clarify my contribution above, we start from a 
> > cross-compiler (nowadays SwiftX) with Forth source for most kernel and 
> > other high-level words. We optimize for performance, not porting ease. 
> > The most challenging steps are:
> > 
> > 1. Designing the VM for the new target (register usage and other 
> > optimizations), then writing the assembler and the required primitives.
> > 
> > 2. Working out how to run the umbilical for a seamlessly interactive 
> > development environment. The actual nature of the link depends on the 
> > target hardware. Most target hardware uses a serial line connected to an 
> > onboard serial port; the NXP 68332 and 68HC16 use NXP’s Background 
> > Debugging Mode (BDM), and communicate via a parallel port.
> > 
> > 3. Writing the user manual for the target.
> > 
> > The job is done when we have a tested, documented, releasable product, 
> > including libraries with hundreds of routines, such as:
> > 
> >      * integer and fixed-point fraction arithmetic and transcendental 
> > functions
> >      * string handling
> >      * clock and calendar
> >      * number conversions
> >      * drivers for serial ports, clock, and other devices and many 
> > others, depending on the target CPU
> > 
> > Cheers,
> > Elizabeth
> > 
> Looking at the source code of SwiftForth I can see that is well 
> organized and easy to follow, the one section that will take a little 
> time studying is the optimizer.
> 
> I have worked on text based optimizers in the past and was able to 
> generate extremely good code but the optimizer was very complex and not 
> very fast as I would have liked, but it was extremely flexible and quite 
> capable. Using a template file to control the conversion of the 
> generated code. It used a Balanced Tree + to store and manipulate the 
> code. Being highly recursive is what made it slower but also gave it the 
> capacity to generate code that looked like a decent programmer wrote it 
> by hand. A negative was that once the final code was generated it was 
> difficult to link it back to the original source as the final product 
> often bore no resemblance to the original code. But all of that was 
> controlled by the user and how many interacting rules one had.
> 
> -- 
> Cecil - k5nwa

Non-interactive Forth code can be stored in a simple linear database of lists, names being the list headers, code the list body as sequence of symbols or literal parameters. Once you have the database of a Forth kernel, pattern recognistion, peephole optimization, target code reduction are rather easy jobs. F.ex. recursion from the entry word (e.g. MAIN) is perfect to minimize the optimized target database.

Thereafter, to generate code from the target database, it is a more or less linear translation of the target database from top to bottom to assembler. Other backends could spill out direct machine code or whatever is needed.

Prolog is an excellent language to do this efficiently and with very compact program code. Adding/changing new optimizer rules is easy.

In the 80s I did all this with Turbo Prolog, but then had to move to other jobs. Perhaps I should revitalize it when I'm retired...

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

#58553

On 5/3/2017 12:29 AM, minforth@arcor.de wrote:
> Am Dienstag, 2. Mai 2017 22:39:08 UTC+2 schrieb Cecil - k5nwa:

>> I have worked on text based optimizers in the past and was able to
>> generate extremely good code but the optimizer was very complex and not
>> very fast as I would have liked, but it was extremely flexible and quite
>> capable. Using a template file to control the conversion of the
>> generated code. It used a Balanced Tree + to store and manipulate the
>> code. Being highly recursive is what made it slower but also gave it the
>> capacity to generate code that looked like a decent programmer wrote it
>> by hand. A negative was that once the final code was generated it was
>> difficult to link it back to the original source as the final product
>> often bore no resemblance to the original code. But all of that was
>> controlled by the user and how many interacting rules one had.
>>
>> -- 
>> Cecil - k5nwa
> 
> Non-interactive Forth code can be stored in a simple linear database of lists, names being the list headers, code the list body as sequence of symbols or literal parameters. Once you have the database of a Forth kernel, pattern recognistion, peephole optimization, target code reduction are rather easy jobs. F.ex. recursion from the entry word (e.g. MAIN) is perfect to minimize the optimized target database.
> 
> Thereafter, to generate code from the target database, it is a more or less linear translation of the target database from top to bottom to assembler. Other backends could spill out direct machine code or whatever is needed.
> 
> Prolog is an excellent language to do this efficiently and with very compact program code. Adding/changing new optimizer rules is easy.
> 
> In the 80s I did all this with Turbo Prolog, but then had to move to other jobs. Perhaps I should revitalize it when I'm retired...
> 

I like Turbo Prolog, Borland did not write that software but marketed 
it, the originators had their enhanced version called PDC Prolog, now 
they have Visual Prolog, I have a copy of all three versions but my 
Visual Prolog is rather an old version its V5.3 , I believe the current 
version is 7.6, PDC and Turbo Prolog are DOS based so the will not even 
run in Windows 10.

Prolog is an interesting language that requires a different way of 
thinking but its very effective at certain kinds of problems, smart text 
processing being one of them. My funky translator/macro processor was 
written in C, unfortunately the code is lost, the original was written 
under CDOS an enhanced version of CPM for Z80 processors using my own 
homemade version of a C compiler, but with minor changes it was able to 
compile later under Turbo C.

-- 
Cecil - k5nwa

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

#58558

Am Mittwoch, 3. Mai 2017 08:12:32 UTC+2 schrieb Cecil - k5nwa:
> On 5/3/2017 12:29 AM, minforth@arcor.de wrote:
> > Am Dienstag, 2. Mai 2017 22:39:08 UTC+2 schrieb Cecil - k5nwa:
> 
> >> I have worked on text based optimizers in the past and was able to
> >> generate extremely good code but the optimizer was very complex and not
> >> very fast as I would have liked, but it was extremely flexible and quite
> >> capable. Using a template file to control the conversion of the
> >> generated code. It used a Balanced Tree + to store and manipulate the
> >> code. Being highly recursive is what made it slower but also gave it the
> >> capacity to generate code that looked like a decent programmer wrote it
> >> by hand. A negative was that once the final code was generated it was
> >> difficult to link it back to the original source as the final product
> >> often bore no resemblance to the original code. But all of that was
> >> controlled by the user and how many interacting rules one had.
> >>
> >> -- 
> >> Cecil - k5nwa
> > 
> > Non-interactive Forth code can be stored in a simple linear database of lists, names being the list headers, code the list body as sequence of symbols or literal parameters. Once you have the database of a Forth kernel, pattern recognistion, peephole optimization, target code reduction are rather easy jobs. F.ex. recursion from the entry word (e.g. MAIN) is perfect to minimize the optimized target database.
> > 
> > Thereafter, to generate code from the target database, it is a more or less linear translation of the target database from top to bottom to assembler. Other backends could spill out direct machine code or whatever is needed.
> > 
> > Prolog is an excellent language to do this efficiently and with very compact program code. Adding/changing new optimizer rules is easy.
> > 
> > In the 80s I did all this with Turbo Prolog, but then had to move to other jobs. Perhaps I should revitalize it when I'm retired...
> > 
> 
> I like Turbo Prolog, Borland did not write that software but marketed 
> it, the originators had their enhanced version called PDC Prolog, now 
> they have Visual Prolog, I have a copy of all three versions but my 
> Visual Prolog is rather an old version its V5.3 , I believe the current 
> version is 7.6, PDC and Turbo Prolog are DOS based so the will not even 
> run in Windows 10.
> 
> Prolog is an interesting language that requires a different way of 
> thinking but its very effective at certain kinds of problems, smart text 
> processing being one of them. My funky translator/macro processor was 
> written in C, unfortunately the code is lost, the original was written 
> under CDOS an enhanced version of CPM for Z80 processors using my own 
> homemade version of a C compiler, but with minor changes it was able to 
> compile later under Turbo C.
> 
> -- 
> Cecil - k5nwa

You might also like Holon Forth that holds its own sources in an internal database 
http://www.holonforth.com/

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

#58608

On 5/3/2017 4:06 AM, minforth@arcor.de wrote:
> Am Mittwoch, 3. Mai 2017 08:12:32 UTC+2 schrieb Cecil - k5nwa:
>> On 5/3/2017 12:29 AM, minforth@arcor.de wrote:
>>> Am Dienstag, 2. Mai 2017 22:39:08 UTC+2 schrieb Cecil - k5nwa:
>>
>>>> I have worked on text based optimizers in the past and was able to
>>>> generate extremely good code but the optimizer was very complex and not
>>>> very fast as I would have liked, but it was extremely flexible and quite
>>>> capable. Using a template file to control the conversion of the
>>>> generated code. It used a Balanced Tree + to store and manipulate the
>>>> code. Being highly recursive is what made it slower but also gave it the
>>>> capacity to generate code that looked like a decent programmer wrote it
>>>> by hand. A negative was that once the final code was generated it was
>>>> difficult to link it back to the original source as the final product
>>>> often bore no resemblance to the original code. But all of that was
>>>> controlled by the user and how many interacting rules one had.
>>>>
>>>> -- 
>>>> Cecil - k5nwa
>>>
>>> Non-interactive Forth code can be stored in a simple linear database of lists, names being the list headers, code the list body as sequence of symbols or literal parameters. Once you have the database of a Forth kernel, pattern recognistion, peephole optimization, target code reduction are rather easy jobs. F.ex. recursion from the entry word (e.g. MAIN) is perfect to minimize the optimized target database.
>>>
>>> Thereafter, to generate code from the target database, it is a more or less linear translation of the target database from top to bottom to assembler. Other backends could spill out direct machine code or whatever is needed.
>>>
>>> Prolog is an excellent language to do this efficiently and with very compact program code. Adding/changing new optimizer rules is easy.
>>>
>>> In the 80s I did all this with Turbo Prolog, but then had to move to other jobs. Perhaps I should revitalize it when I'm retired...
>>>
>>
>> I like Turbo Prolog, Borland did not write that software but marketed
>> it, the originators had their enhanced version called PDC Prolog, now
>> they have Visual Prolog, I have a copy of all three versions but my
>> Visual Prolog is rather an old version its V5.3 , I believe the current
>> version is 7.6, PDC and Turbo Prolog are DOS based so the will not even
>> run in Windows 10.
>>
>> Prolog is an interesting language that requires a different way of
>> thinking but its very effective at certain kinds of problems, smart text
>> processing being one of them. My funky translator/macro processor was
>> written in C, unfortunately the code is lost, the original was written
>> under CDOS an enhanced version of CPM for Z80 processors using my own
>> homemade version of a C compiler, but with minor changes it was able to
>> compile later under Turbo C.
>>
>> -- 
>> Cecil - k5nwa
> 
> You might also like Holon Forth that holds its own sources in an internal database
> http://www.holonforth.com/
> 
I do like the principle of Holon Forth, it makes it very easy to keep 
the source code organized. A long time ago I had high hopes for it but 
it was not to be.

At one point I even started working on creating a version for another 
CPU but since at the time the full source was not available, one needed 
the help of the author to integrate my newly written assembler, but the 
author asked me to not bother as it was not worth the effort.

This was a big disappointment after going through all the work to get 
the assembler working and tested. The result besides being disappointed 
was to give up using it altogether. I believe now the full source is 
available but I rather late in the day as the source is for a DOS Forth 
and Windows no longer supports DOS.

On a side project that I have worked on an off for a while, mostly off, 
I started creating a Forth VM in 386 assembler and have a good deal of 
it finished but my heart is not in it. Still it could be useful in the 
future if I finish it as I already have 86 Forth Words in assembler. 
Instead I been writing a Forth VM in C with about 45 primitives and the 
rest will be in Forth, that is 80% done with all the primitives working 
but now I'm using them to build a full system in Forth.

Every once in a while I check the status of the site since they had a 
version that did not have Forth in it but was just an editor which could 
be useful but the page on that product does not have a link to download 
it so the whole thing is a lost cause now.

After a while the author converted the software to generate and use 
Tcl/Tk, a Forth compiler/interpreter written in an interpreter just 
doesn't work out with me as it would be too slow, even now I'm in the 
middle of a project to create an easy to modify Forth in C which is too 
slow for my taste but I did not have a lot of choice as I wanted to 
avoid having to learn assembler for a variety of CPUs.

-- 
Cecil - k5nwa

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

#58617

Am Mittwoch, 3. Mai 2017 20:53:00 UTC+2 schrieb Cecil - k5nwa:
> On 5/3/2017 4:06 AM, minforth@arcor.de wrote:
> > Am Mittwoch, 3. Mai 2017 08:12:32 UTC+2 schrieb Cecil - k5nwa:
> >> On 5/3/2017 12:29 AM, minforth@arcor.de wrote:
> >>> Am Dienstag, 2. Mai 2017 22:39:08 UTC+2 schrieb Cecil - k5nwa:
> >>
> >>>> I have worked on text based optimizers in the past and was able to
> >>>> generate extremely good code but the optimizer was very complex and not
> >>>> very fast as I would have liked, but it was extremely flexible and quite
> >>>> capable. Using a template file to control the conversion of the
> >>>> generated code. It used a Balanced Tree + to store and manipulate the
> >>>> code. Being highly recursive is what made it slower but also gave it the
> >>>> capacity to generate code that looked like a decent programmer wrote it
> >>>> by hand. A negative was that once the final code was generated it was
> >>>> difficult to link it back to the original source as the final product
> >>>> often bore no resemblance to the original code. But all of that was
> >>>> controlled by the user and how many interacting rules one had.
> >>>>
> >>>> -- 
> >>>> Cecil - k5nwa
> >>>
> >>> Non-interactive Forth code can be stored in a simple linear database of lists, names being the list headers, code the list body as sequence of symbols or literal parameters. Once you have the database of a Forth kernel, pattern recognistion, peephole optimization, target code reduction are rather easy jobs. F.ex. recursion from the entry word (e.g. MAIN) is perfect to minimize the optimized target database.
> >>>
> >>> Thereafter, to generate code from the target database, it is a more or less linear translation of the target database from top to bottom to assembler. Other backends could spill out direct machine code or whatever is needed.
> >>>
> >>> Prolog is an excellent language to do this efficiently and with very compact program code. Adding/changing new optimizer rules is easy.
> >>>
> >>> In the 80s I did all this with Turbo Prolog, but then had to move to other jobs. Perhaps I should revitalize it when I'm retired...
> >>>
> >>
> >> I like Turbo Prolog, Borland did not write that software but marketed
> >> it, the originators had their enhanced version called PDC Prolog, now
> >> they have Visual Prolog, I have a copy of all three versions but my
> >> Visual Prolog is rather an old version its V5.3 , I believe the current
> >> version is 7.6, PDC and Turbo Prolog are DOS based so the will not even
> >> run in Windows 10.
> >>
> >> Prolog is an interesting language that requires a different way of
> >> thinking but its very effective at certain kinds of problems, smart text
> >> processing being one of them. My funky translator/macro processor was
> >> written in C, unfortunately the code is lost, the original was written
> >> under CDOS an enhanced version of CPM for Z80 processors using my own
> >> homemade version of a C compiler, but with minor changes it was able to
> >> compile later under Turbo C.
> >>
> >> -- 
> >> Cecil - k5nwa
> > 
> > You might also like Holon Forth that holds its own sources in an internal database
> > http://www.holonforth.com/
> > 
> I do like the principle of Holon Forth, it makes it very easy to keep 
> the source code organized. A long time ago I had high hopes for it but 
> it was not to be.
> 
> At one point I even started working on creating a version for another 
> CPU but since at the time the full source was not available, one needed 
> the help of the author to integrate my newly written assembler, but the 
> author asked me to not bother as it was not worth the effort.
> 
> This was a big disappointment after going through all the work to get 
> the assembler working and tested. The result besides being disappointed 
> was to give up using it altogether. I believe now the full source is 
> available but I rather late in the day as the source is for a DOS Forth 
> and Windows no longer supports DOS.
> 
> On a side project that I have worked on an off for a while, mostly off, 
> I started creating a Forth VM in 386 assembler and have a good deal of 
> it finished but my heart is not in it. Still it could be useful in the 
> future if I finish it as I already have 86 Forth Words in assembler. 
> Instead I been writing a Forth VM in C with about 45 primitives and the 
> rest will be in Forth, that is 80% done with all the primitives working 
> but now I'm using them to build a full system in Forth.
> 
> Every once in a while I check the status of the site since they had a 
> version that did not have Forth in it but was just an editor which could 
> be useful but the page on that product does not have a link to download 
> it so the whole thing is a lost cause now.
> 
> After a while the author converted the software to generate and use 
> Tcl/Tk, a Forth compiler/interpreter written in an interpreter just 
> doesn't work out with me as it would be too slow, even now I'm in the 
> middle of a project to create an easy to modify Forth in C which is too 
> slow for my taste but I did not have a lot of choice as I wanted to 
> avoid having to learn assembler for a variety of CPUs.
> 
> -- 
> Cecil - k5nwa

What a mess: spending significant lifetime to re-invent the wheel all over again. ;-)

I don't want to sound disrespectful, but it might have been better to join forces with somebody, or spend some little money and get support from one of the professional vendors.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web