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 2 of 2 — ← Prev page 1 [2]

#58635

четверг, 4 мая 2017 г., 8:23:22 UTC+3 пользователь minf...@arcor.de написал:
> 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.

In this case, why don't suggest to AMD to stop their CPU development? They can spend some little money and get support from the Intel...

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

#58863

On Tue, 2 May 2017, 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.
>
> 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.
>

By not using C libraries, a C based forth can be re-hosted in a day or so 
on native implementations (uart recoding mostly), and on hosted 
implementations, almost instantaneously.

One file Forth (github.com/paraplegic/OneFileForth.git) runs on Linux, and 
BSD, DOS, 32 and 64bit, QEMU Arm (VersatilePB), and a few others (PPC, 
x86, x64, Arm) etc.

Should you use the forth in forth approach, perhaps the OneFileForth might 
make a good bootstrap in which to write your assembler, should you wish to 
compile on the platform you're targeting.  Not the fastest C based 
Forth, nor is it the most standard, but dead simple to build/link, and 
runs on just about everything.

I will be doing a Risc-V native shortly, and refactoring to add the lie to 
the OneFileForth name, by extracting the i/o on a machine specific basis, 
and vectoring them for each platform, but that will have to await some 
free time.

Cheers,
Rob.

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

#58532

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

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

The quick answer: between 3 days and 3 months. The first number is
for an ITC Forth for a CPU you are familiar with starting from
another Forth. The second number is for a fully optimising VFX grade
Forth for another CPU for which you have no tools.

The long answer is that the commercial vendors don't write new
kernels unless they have to - say the default standard changes
significantly. MPE has written three kernels in 30+ years.
We have however ported the VFX code generator to about 6 CPU
architectures in 15 years. In order to do this port, you have
to write an assembler, disassembler, code generator and some
target code. The first VFX code generator used about 18 person-
months. Nowadays, we would quote you for three months work -
it just depends how much a peformance uplify of 10:1 is worth.

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]

#58537

On 5/2/2017 2:41 PM, Stephen Pelc wrote:
> On Mon, 1 May 2017 02:24:38 -0700 (PDT), Joel Rees
> <joel.rees@gmail.com> wrote:
> 
>> For those who regularly implement kernels in new CPU architectures, about h=
>> ow long does it take on average? And how does your current expected time co=
>> mpare with your first conversion time?
> 
> The quick answer: between 3 days and 3 months. The first number is
> for an ITC Forth for a CPU you are familiar with starting from
> another Forth. The second number is for a fully optimising VFX grade
> Forth for another CPU for which you have no tools.
> 
> The long answer is that the commercial vendors don't write new
> kernels unless they have to - say the default standard changes
> significantly. MPE has written three kernels in 30+ years.
> We have however ported the VFX code generator to about 6 CPU
> architectures in 15 years. In order to do this port, you have
> to write an assembler, disassembler, code generator and some
> target code. The first VFX code generator used about 18 person-
> months. Nowadays, we would quote you for three months work -
> it just depends how much a peformance uplify of 10:1 is worth.
> 
> Stephen
> 
The current port that I'm working on will take an estimate of two to 
three weeks of man-hours spread over a couple of month, I will not be 
including and optimizer for the generated code, that task is a lot of 
effort that will get done as a separate project once I have a working 
compiler. My main goal now is portability, later the optimizer will 
become more important. This process includes learning the implementation 
language which will cause a slowdown of the whole process.

A project follow will be to implement the compiler using VFX Forth as 
the implementing language, that I estimate will be a shorter process as 
Forth is language that allows code to be written and debugged faster, 
plus the fact that some of the existing features in the VFX Forth 
compiler can be utilized to make the process faster. This will be my 
first major project in VFX Forth so there will be a learning curve also 
although not a large as with the Go Language.

-- 
Cecil - k5nwa

[toc] | [prev] | [standalone]

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

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

csiph-web