[CLOSED] TP/BP compatibility

[440bx]

Prove me wrong.... You can't. End of story.
...
babble
...
Even if it was open sourced it would not be very useful.

No one needs to prove you wrong, you already proved yourself wrong with this statement:

TP/BP are orginally written in hand-optimized TASM and is quite unreadable and not even properly documented.

It would be useful to show people who want to learn how to write a compiler.  It would also show that using assembler to write a compiler should only be considered for a language that is simple (and TP7 is a very simple compiler - try writing g++ in assembler.)

It is no surprise you found the code unreadable and, even less of a surprise that you didn't understand a line of it.  It's unlikely any amount of documentation would have made a difference for you.  (lobotomies are not currently considered "documentation".)

The Borland family and children have never been self-hosted compilers like FPC is.
Note TP mode is nearly 100% able to compile real TP code. It has more options, so the other way around is not true.
...
And plz do not come up with hacks that rely on compiler internals. Stick to the language supported by TP/BP.
(You could write self modifying code in TP, you are hard-pressed to do the same in FPC {$mode TP}

You have quite a talent to go off on a tangent.  There are, as you read this, 2647 Chinese individuals in the city of Beijing eating dumplings.  Do not come up with hacks like corn flour to make the dumplings, also you'd be hard pressed to steam them on a local geyser and, self eating dumplings are not part of the Chinese culture.

[Thaddy]

You have quite a talent to go off on a tangent.  There are, as you read this, 2647 Chinese individuals in the city of Beijing eating dumplings.  Do not come up with hacks like corn flour to make the dumplings, also you'd be hard pressed to steam them on a local geyser and, self eating dumplings are not part of the Chinese culture.

Yes, but I actually saw that code. And the part I saw was actually explained to me by the compiler team, which included Anders (not Chuck).
It is not easy, because it uses every optimization trick in the book - legal or not -.
The TP 1.0 compiler can easily be reverse engineered if you want. Since it has no high level dependencies or libraries apart from the DOS interrupts. Brown's interrupt table rings any bells?
That would be a good starting point for nitwits. TP/BP 7 already relied on - table based - code generators and were highly sophisticated for the time. But still just - almost, C code for the text mode IDE exists - 100% assembler.

Nowadays, basic compilers are much, much easier to write. No hoops, plain structure. That's NOT how Turbo Pascal was written. As its family members TurboBasic and Turbo C were not (they share the same start up code and soft-float code).

I was there, you were not!

[440bx]

I was there, you were not!

Unfortunately, they didn't explain Boolean operator precedence to you.  They probably thought you knew that already. (most, probably all, computer science graduates do.)

At least you're no longer stating that having the code would not be useful.  You're making progress.

[marcov]

It would be useful to show people who want to learn how to write a compiler.

Well... I would not advise that.

  It would also show that using assembler to write a compiler should only be considered for a language that is simple (and TP7 is a very simple compiler - try writing g++ in assembler.)

The dialect is simple, but not the implementation that was obfuscated due memory and speed constraints, and it is in ASM. And I would not wish that kind of stuff upon my worst enemies, let alone unsuspecting beginners.

Really, it is only useful for minimalists and historians.

[440bx]

It would be useful to show people who want to learn how to write a compiler.

Well... I would not advise that.

I should have added "in assembler".

The dialect is simple, but not the implementation that was obfuscated due memory and speed constraints, and it is in ASM. And I would not wish that kind of stuff upon my worst enemies, let alone unsuspecting beginners.

Really, it is only useful for minimalists and historians.

The implementation gets complicated not because of the compiler but because of having to implement a fully working IDE and a debugger in a segmented architecture on an O/S (MS-DOS) that only provides very basic services.

The command line version (no IDE, no debugger), I won't say is simple but, is not out of reach of a dedicated individual who wants to learn.

Part of what makes it interesting is that,  it is the source code of a commercially successful product. 

I do agree that, it shouldn't be the anyone's first exposure to writing a compiler. <chuckle>

[julkas]

I am trying port GUI module for embedded systems from C to Pascal and I want compatible code. Where is the problem? I can't understand.
Forum has rules, we must follow them.

[440bx]

I am trying port GUI module for embedded systems from C to Pascal and I want compatible code.

Since this is for an embedded system, I'm fairly sure the answer to the question I'm about to ask is "no" but, just in case, does the port have to be 16bit or would it be acceptable to port it to 32bit in the process of it porting to Pascal ?

[julkas]

Original C code is here - https://github.com/achimdoebler/UGUI

[PascalDragon]

I am trying port GUI module for embedded systems from C to Pascal and I want compatible code.

Since this is for an embedded system, I'm fairly sure the answer to the question I'm about to ask is "no" but, just in case, does the port have to be 16bit or would it be acceptable to port it to 32bit in the process of it porting to Pascal ?

And even if it would have to be 16-bit I'd suggest to use FPC nevertheless as it supports i8086 as well (for MSDOS, Win16 and Embedded) and allows to use the Object Pascal language features.

[julkas]

I am trying port GUI module for embedded systems from C to Pascal and I want compatible code.

Since this is for an embedded system, I'm fairly sure the answer to the question I'm about to ask is "no" but, just in case, does the port have to be 16bit or would it be acceptable to port it to 32bit in the process of it porting to Pascal ?

And even if it would have to be 16-bit I'd suggest to use FPC nevertheless as it supports i8086 as well (for MSDOS, Win16 and Embedded) and allows to use the Object Pascal language features.

I use Lazarus/FPC as primary IDE.
TP/BP is still alive (whether you like it or not) ...  see - System Requirements http://www.on-time.com/rtkernel-dos.htm

[Thaddy]

TP/BP is still alive (whether you like it or not) ...  see - System Requirements http://www.on-time.com/rtkernel-dos.htm

Yes, it is even free. But be careful: TP mode is richer in  syntax than the original. You have to be careful to only use syntax that is definitely supported by the original TP if you build new code on top of rt-kernel.

[PascalDragon]

I am trying port GUI module for embedded systems from C to Pascal and I want compatible code.

Since this is for an embedded system, I'm fairly sure the answer to the question I'm about to ask is "no" but, just in case, does the port have to be 16bit or would it be acceptable to port it to 32bit in the process of it porting to Pascal ?

And even if it would have to be 16-bit I'd suggest to use FPC nevertheless as it supports i8086 as well (for MSDOS, Win16 and Embedded) and allows to use the Object Pascal language features.

I use Lazarus/FPC as primary IDE.
TP/BP is still alive (whether you like it or not) ...  see - System Requirements http://www.on-time.com/rtkernel-dos.htm

I didn't write about TP/BP being alive or not, but simply that FPC provides more features.
Of course interfacing with existing TP/BP based (binary) code is a valid reason to use TP/BP. Though maybe the author of the software could be asked to make their software compatible to FPC's i8086-msdos port as well.

[julkas]

As I understand TP7 supports pointer arithmetic only for PChar type.
So to implement pointer arithmetic for other types I convert base type to PChar and then back. Example -

Code: Pascal  [Select][+][-]

1. program zzz;
2. {$X+}
3. type
4.   PWord = ^Word;
5.  
6. const
7.   arr: array[0..3] of Word = ($FFFF, 0, $FFFF, 0);
8. var
9.   p: PWord;
10.  
11. begin
12.   p := @arr;
13.   (* p := p + 1; gives - Error 26: Type mismatch. *)
14.   p := PWord(PChar(p) + SizeOf(Word));
15.   WriteLn(p^);
16.   ReadLn;
17. end.

Is there other solutions? Suggestions, hints, ...

[marcov]

I use Lazarus/FPC as primary IDE.
TP/BP is still alive (whether you like it or not) ...  see - System Requirements http://www.on-time.com/rtkernel-dos.htm

Probably old. But one reference on the internet means that a product/project is alive? Well, then probably nothing is dead. Even if it is just graffiti on the walls of Pompeii

[julkas]

Well, then probably nothing is dead. Even if it is just graffiti on the walls of Pompeii

Ya. +1.