• UR/FORTH information request.

    From Luca Masini@21:1/5 to All on Thu Jan 5 14:29:01 2023
    Unfortunately it seems that UR/FORTH with manuals (an old DOS based Forth from LMI) is lost in the cyberspace.

    The reason I am interested (apart from my general interest in computer archaeology) is explained here -> https://web.archive.org/web/19990922041206/www.cerfnet.com/~lmi/catalog/catalog1.htm

    That is: "May be linked with object modules created with an assembler or other high-level language compilers"

    Also at page 21 of this -> http://www.forth.org/fd/FD-V13N6.pdf

    That is: "UR/FORTH is one of the few Forths in this review that is compatible with the DOS linker"

    Maybe someone can give me information on how to find or buy it.

    Perhaps someone knows another Forth WRITTEN IN ASSEMBLER OR IN FORTH that is compatible with normal libraries (i.e. that can be linked easily with C/C++ libraries).

    In the limited information I found about UR/FORTH, it seems that it was possible to link only the Forth words used in the program with generic libraries (.LIB)
    I suppose you can do this if you split each Forth word of the dictionary in a single .OBJ and then make a .LIB with them.
    But it is just my supposition and I'm curious to check how they implemented it.

    PS: I'm just curious and I would like to see how UR/FORTH implemented it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcel Hendrix@21:1/5 to luca.a...@gmail.com on Thu Jan 5 22:59:24 2023
    On Thursday, January 5, 2023 at 11:29:03 PM UTC+1, luca.a...@gmail.com wrote: [..]
    That is: "May be linked with object modules created with an assembler or other high-level language compilers"
    [..]
    You want to have a look at FLAG (MPE website).

    -marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Luca Masini on Fri Jan 6 11:19:48 2023
    Luca Masini <luca.a.masini@gmail.com> writes:
    Perhaps someone knows another Forth WRITTEN IN ASSEMBLER OR IN FORTH that is compatible with normal libraries (i.e. that can be linked easily with C/C++ libraries).

    The more professional Forth systems (Gforth, iForth, SwiftForth, VFX,
    have not looked) have C interfaces (you may remember my talk at
    Forth-Tagung 2007; BTW, nice to see that you are still interested in
    Forth). They are all mostly written in Forth, but Gforth may have
    more C code than fits your criteria. SwiftForth may be what you are
    looking for, but looking at SwiftForth/src/kernel/linux/imports.f
    gives me a rough idea how it is implemented, but I did not follow that
    rabbit hole to its bottom.

    - 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: https://forth-standard.org/
    EuroForth 2022: https://euro.theforth.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hans Bezemer@21:1/5 to luca.a...@gmail.com on Fri Jan 6 05:37:49 2023
    On Thursday, January 5, 2023 at 11:29:03 PM UTC+1, luca.a...@gmail.com wrote:
    Perhaps someone knows another Forth WRITTEN IN ASSEMBLER OR IN FORTH that is compatible with normal libraries (i.e. that can be linked easily with C/C++ libraries).
    Is there a specific reason you omit C based Forths, like ATLAST, FICL or 4tH?

    They *will* link with C of course.. I'm not sure about the DOS part (except for 4tH obviously).

    Hans Bezemer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From none) (albert@21:1/5 to luca.a.masini@gmail.com on Fri Jan 6 15:28:01 2023
    In article <e4fb5d56-d303-4868-b04a-ca60413072cen@googlegroups.com>,
    Luca Masini <luca.a.masini@gmail.com> wrote:
    <SNIP>
    Perhaps someone knows another Forth WRITTEN IN ASSEMBLER OR IN FORTH
    that is compatible with normal libraries (i.e. that can be linked
    easily with C/C++ libraries).

    That is devoid of meaning. Each operating system, DOS VMS UNIX Linux
    Windows has a different binary object format, for single object files
    and for shared libraries ("dll"'s).

    The proper question is
    Give a Forth for VMS (DOS .. ) that can interface to compiled code?

    Lately there is some standardisation at the ELF front and at the Microsoft front.

    I had a job where interfacing to object libraries was an issue, because
    the object libraries were a given, and the company out growed the compiler. They could not be used by the gnu compiler.
    I changed the gnu compiler ...
    Interfacing to object ("c"-libraries) is not cast in stone.

    Groetjes Albert
    --
    Don't praise the day before the evening. One swallow doesn't make
    spring. You must not say "hey" before you have crossed the bridge.
    Don't sell the hide of the bear until you shot it. Better one bird in
    the hand than ten in the air. - the Wise from Antrim -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Masini@21:1/5 to the.bee...@gmail.com on Fri Jan 6 10:44:39 2023
    On Friday, January 6, 2023 at 2:37:51 PM UTC+1, the.bee...@gmail.com wrote:

    On Thursday, January 5, 2023 at 11:29:03 PM UTC+1, luca.a...@gmail.com wrote:
    Perhaps someone knows another Forth WRITTEN IN ASSEMBLER OR IN FORTH that is compatible with normal libraries (i.e. that can be linked easily with C/C++ libraries).
    Is there a specific reason you omit C based Forths, like ATLAST, FICL or 4tH?

    Not a practical reason (I used for ex. pforth that can easily be extended with C library).
    During these last Christmas vacations I used ForthCMP by Tom Almy for a small retro-Project.
    ForthCMP used to be a "pure" compiler for UR/FORTH (similar to your 4tH) and I have searched info about UR/FORTH.

    MfG

    Luca Masini.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hans Bezemer@21:1/5 to luca.a...@gmail.com on Sun Jan 8 05:36:46 2023
    On Friday, January 6, 2023 at 7:44:41 PM UTC+1, luca.a...@gmail.com wrote:
    ForthCMP used to be a "pure" compiler for UR/FORTH (similar to your 4tH) and I have searched info about UR/FORTH.
    I've known about ForthCMP for a looooooong time - and I admire the project. I've never been able to find out how it ticks - the source is not available - but I
    assume it has quite a different architecture than 4tH.

    There are also significant differences in the design objectives:
    (1) 4tH was created to be embedded in C - with low memory overhead.
    You can even embed precompiled code, so you won't need to link the
    compiler in - only the runtime. The 4tH runtime allocates only what's
    needed to make the program run. That's a difference with languages
    like ATLAST or FICL. Of course, reflection suffers ;-) ForthCMP was
    created as a standalone compiler;

    (2) 4tH was meant to be highly portable. ForthCMP was designed for
    a specific platform. Consequence is that where ForthCMP is much
    faster due to native code generation, 4tH requires a VM in order to run.

    (3) Applications are hence wildly different. Since ForthCMP is much
    closer to the bare iron, it's much better suited for system applications
    like TSRs, drivers, ROMmable applications, etc.

    I cannot say that the existence of ForthCMP influenced 4tH very much.
    First of all because its source is not open - and second I became only
    aware of the project when the development of 4tH was already underway
    for a while.

    So, in short, IMHO the resemblance is superficial - apart from both not conforming to the standard ANS Forth VM model.

    Hans Bezemer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcel Hendrix@21:1/5 to luca.a...@gmail.com on Sun Jan 8 08:07:24 2023
    On Friday, January 6, 2023 at 7:44:41 PM UTC+1, luca.a...@gmail.com wrote:
    On Friday, January 6, 2023 at 2:37:51 PM UTC+1, the.bee...@gmail.com wrote:

    On Thursday, January 5, 2023 at 11:29:03 PM UTC+1, luca.a...@gmail.com wrote:
    Perhaps someone knows another Forth WRITTEN IN ASSEMBLER OR IN FORTH that is compatible with normal libraries (i.e. that can be linked easily with C/C++ libraries).
    Is there a specific reason you omit C based Forths, like ATLAST, FICL or 4tH?
    Not a practical reason (I used for ex. pforth that can easily be extended with C library).
    During these last Christmas vacations I used ForthCMP by Tom Almy for a small retro-Project.
    ForthCMP used to be a "pure" compiler for UR/FORTH (similar to your 4tH) and I have searched info about UR/FORTH.

    MfG

    Luca Masini.

    Maybe you also should have a look at TCOM, from Tom Zimmer.
    I actually used that compiler to write DOS commandline utilities
    for my employer at the time. It ran rings around Turbo Pascal.

    -marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to Marcel Hendrix on Mon Jan 9 12:30:39 2023
    On 9/01/2023 3:07 am, Marcel Hendrix wrote:
    On Friday, January 6, 2023 at 7:44:41 PM UTC+1, luca.a...@gmail.com wrote:
    On Friday, January 6, 2023 at 2:37:51 PM UTC+1, the.bee...@gmail.com wrote: >>
    On Thursday, January 5, 2023 at 11:29:03 PM UTC+1, luca.a...@gmail.com wrote:
    Perhaps someone knows another Forth WRITTEN IN ASSEMBLER OR IN FORTH that is compatible with normal libraries (i.e. that can be linked easily with C/C++ libraries).
    Is there a specific reason you omit C based Forths, like ATLAST, FICL or 4tH?
    Not a practical reason (I used for ex. pforth that can easily be extended with C library).
    During these last Christmas vacations I used ForthCMP by Tom Almy for a small retro-Project.
    ForthCMP used to be a "pure" compiler for UR/FORTH (similar to your 4tH) and I have searched info about UR/FORTH.

    MfG

    Luca Masini.

    Maybe you also should have a look at TCOM, from Tom Zimmer.
    I actually used that compiler to write DOS commandline utilities
    for my employer at the time. It ran rings around Turbo Pascal.

    In what sense? AFAIK both generated native code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcel Hendrix@21:1/5 to dxforth on Sun Jan 8 18:05:48 2023
    On Monday, January 9, 2023 at 2:30:42 AM UTC+1, dxforth wrote:
    On 9/01/2023 3:07 am, Marcel Hendrix wrote:
    [..]
    Maybe you also should have a look at TCOM, from Tom Zimmer.
    I actually used that compiler to write DOS commandline utilities
    for my employer at the time. It ran rings around Turbo Pascal.
    In what sense? AFAIK both generated native code.

    The Pascal program had many separately compiled modules and
    used closed external libraries. It was very difficult to inspect and
    debug (especially the real-time stuff) because it was object oriented,
    there were shady variables all over the place, and it was becoming
    too large for the 'small model.'

    To write the programs one needed domain knowledge (that
    I had more than the Pascal programmers). The main user was a
    control freak and extremely difficult to work with if he didn't get
    his way exactly (but for some reason he liked me).

    Furthermore, I had the advantage of stepping in when management
    was panicking that they wouldn't see anything back from their
    (sizable) investment. I could therefore start from scratch, and
    negotiated to throw out lots of stuff in order to get quickly to the
    point where results would start to come in. I made it look like they
    could rewrite my 'executable prototype' in Pascal once we got
    there. Of course, the rewrite never happened.

    -marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to Marcel Hendrix on Mon Jan 9 15:25:03 2023
    On 9/01/2023 1:05 pm, Marcel Hendrix wrote:
    On Monday, January 9, 2023 at 2:30:42 AM UTC+1, dxforth wrote:
    On 9/01/2023 3:07 am, Marcel Hendrix wrote:
    [..]
    Maybe you also should have a look at TCOM, from Tom Zimmer.
    I actually used that compiler to write DOS commandline utilities
    for my employer at the time. It ran rings around Turbo Pascal.
    In what sense? AFAIK both generated native code.

    The Pascal program had many separately compiled modules and
    used closed external libraries. It was very difficult to inspect and
    debug (especially the real-time stuff) because it was object oriented,
    there were shady variables all over the place, and it was becoming
    too large for the 'small model.'

    To write the programs one needed domain knowledge (that
    I had more than the Pascal programmers). The main user was a
    control freak and extremely difficult to work with if he didn't get
    his way exactly (but for some reason he liked me).

    Furthermore, I had the advantage of stepping in when management
    was panicking that they wouldn't see anything back from their
    (sizable) investment. I could therefore start from scratch, and
    negotiated to throw out lots of stuff in order to get quickly to the
    point where results would start to come in. I made it look like they
    could rewrite my 'executable prototype' in Pascal once we got
    there. Of course, the rewrite never happened.

    -marcel

    Appears to have been more about programmer and people skills than the
    compilers involved. I'm shocked to hear 3rd party libraries and OOP
    fared so badly when they should have saved the day :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hans Bezemer@21:1/5 to dxforth on Mon Jan 9 08:37:34 2023
    On Monday, January 9, 2023 at 5:25:07 AM UTC+1, dxforth wrote:
    Appears to have been more about programmer and people skills than the compilers involved. I'm shocked to hear 3rd party libraries and OOP
    fared so badly when they should have saved the day :)

    Why are you surprised? In order to do OOP you have to do some horrible hacks. May look so nice on the surface, but below it's sheer horror. And consequently, OOP has a lot of overhead. I do have respect for the guys who write those compilers, because performance of e.g. C++ is often quite reasonable.

    And note that 3rd party stuff is written to be SOLD to braindead managers.
    It's not to show off how good a programmer you are. I can tell you some MS horror stories in that regard.

    It's ALWAYS about the programmer. It's NEVER about the tool. Chuck said it, Dijkstra said it, but we're unable to shove that idea into the thick skulls of those
    who make the decision.

    Let me quote a old colleague of mine: "It's not only remarkable that this tool works as intended - it's remarkable it was done in a day or two without the involvement of half the management and an incessant numbers of meetings that inevitably come with that. Usually, these things require a project run by an external
    party that produces more Prince2 exception reports than actual working code".

    Hans Bezemer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)