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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)