What is best approach for TP (turbo Pascal)/BP compatibility fu1 or fu2As far as compatibility goes, I think they should be the same.
Except when passing nil, that is.Good point. fu2 allows nil whereas fu1 doesn't. That's a consideration that may matter depending on what the function is supposed to do.
Ok, thanks. I am porting C code to Free Pascal. I want BP/TP compatibility (at least TP7). Original code has many functions in the following formExcept when passing nil, that is.Good point. fu2 allows nil whereas fu1 doesn't. That's a consideration that may matter depending on what the function is supposed to do.
As far as compatibility, I don't think it makes any difference.
Ok, thanks. I am porting C code to Free Pascal. I want BP/TP compatibility (at least TP7). Original code has many functions in the following formThe test "if (x == NULL)" indicates that the function can accept a NULL/nil pointer, in that case, fu2 would be the better match to the C function because, fu2 allows a nil/NULL parameter as your C function currently does.where obj is struct. Can I use my fu1 or not?
where obj is struct. Can I use my fu1 or not?The answer to that question is, yes you can, but, if you go that route, the Pascal code for C functions that accept nil as a parameter won't be "parallel". Here is an example of passing nil to a Pascal function declared to take a "var" parameter:
Small addition:I don't use C binding (interfacing), I just traslate C source code to Pascal.
When interfacing with C code containing structures always use {$PACKRECORDS C} otherwise you will get bitten.
The following constructs are comments and are ignored by
the compiler:
{ Any text not containing right brace }
(* Any text not containing star/right parenthesis *)
I compiled unit with Free Pascal and {$mode tp} without errors.
TP7 compiler fails on //.
So // comment not supported in TP7?
No, they aren't. C++ style comments weren't supported by any of Borland's Pascal compilers until almost the 21st century--somewhen between Delphi 3 to 5, don't remember exactly.It's not quite that bad. 20th century Delphi 2 supports // comments.
Ok, so search and replace.
I found also this - program lines have a maximum length of 126 characters.
O great old Pascal!
Who knows - why 126?
You mean (2**7-1)-1? May be. Good observation.I found also this - program lines have a maximum length of 126 characters.
O great old Pascal!
Who knows - why 126?
High(ShortInt) - one char. line separator?
Offtopic - Why TP7 is still closed source? What is the reason?In order of succession: Borland - CodeGear - Embarcadero, this question to the last company.
Offtopic - Why TP7 is still closed source? What is the reason?Serge is right, that question should be directed to Embarcadero (or the company who owns them.)
How declare unsigned DWORD integer in TP7 ?TP7 does _not_ support unsigned 32bit integers.
Any ready to use code?How declare unsigned DWORD integer in TP7 ?TP7 does _not_ support unsigned 32bit integers.
To manipulate unsigned 32bit integers (which you are forced to declared as signed, since there is no alternative) you have to typecast them to pchar. The typecast to pchar causes the code to use relational operators that consider the quantity unsigned.
Disclaimer: I know the above works with Delphi 2 because I routinely use it. I don't remember if it works/worked with TP7.
Any ready to use code?Not TP7 code. I don't even remember the last time I used TP7 but, I can provide an example, for instance
See btypes unit of Wolfgang Ehrhardt util package.Any ready to use code?Not TP7 code. I don't even remember the last time I used TP7 but, I can provide an example, for instanceI know the above works with Delphi 2, I am not sure if it works with TP7. I'd have to look at the code it generates (i.e, does it generate jl (signed) or jb (unsigned))
See btypes unit of Wolfgang Ehrhardt util package.Thank you. For the times I need unsigned 32bit integers, typecasting to pchar does the job.
I believe there's no sourcecode there. It is probably a means of running one of the free versions of TP/BP from the Borland museum in DosBox.Its your opinion. I don't think so.
TP/BP are orginally written in hand-optimized TASM and is quite unreadable and not even properly documented.
I saw parts of it while working at Borland during an exchange program.
Even if it was open sourced it would not be very useful.
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.
Its your opinion. I don't think so.Prove me wrong.... You can't. End of story.
Prove me wrong.... You can't. End of story.No one needs to prove you wrong, you already proved yourself wrong with this statement:
...
babble
...
Even if it was open sourced it would not be very useful.
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.)
The Borland family and children have never been self-hosted compilers like FPC is.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.
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.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).
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.)
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.)
I should have added "in assembler".It would be useful to show people who want to learn how to write a compiler.
Well... I would not advise that.
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.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.
Really, it is only useful for minimalists and historians.
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 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 ?
I use Lazarus/FPC as primary IDE.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 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 ?
TP/BP is still alive (whether you like it or not) ... see - System Requirements http://www.on-time.com/rtkernel-dos.htmYes, 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.
I didn't write about TP/BP being alive or not, but simply that FPC provides more features.I use Lazarus/FPC as primary IDE.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 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 ?
TP/BP is still alive (whether you like it or not) ... see - System Requirements http://www.on-time.com/rtkernel-dos.htm
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
Well, then probably nothing is dead. Even if it is just graffiti on the walls of PompeiiYa. +1.
Well, according to the date at the bottom left the website at least still appears to be updated... *shrugs*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
How disassemble TP/BP compiled units?