Recent

Author Topic: Does Freepascal has everything "must have" functional features as C does  (Read 4927 times)

winni

  • Hero Member
  • *****
  • Posts: 3197
Greetings!

Speaking to FPC3.0,just want to know whether freepascal has everything "must have" as those features in C?And how about pointers in fpc,it has the same strong ability as C,let's say in a system programming environment.

I am not tending to leading a language war,rather,just expecting everything C can do freepascal can do as well and nothing "must have" features is missing in Freepascal.

Best Regards,
Peter

Hi!

To make it short:

fpc is a superset of C.

Take care: The current stable version is 3.2.2

To show you what is possible with fpc have a look at this site:

Operating Systems written in FPC

https://wiki.freepascal.org/Operating_Systems_written_in_FPC

Winni




MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
fpc is a superset of C.

If that is even superficially true, please show me an FPC implementation of Duff's Device.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
fpc is a superset of C.

If that is even superficially true, please show me an FPC implementation of Duff's Device.

Sure. Just show me a real world application.

P.s. OP probably meant for "FPC is a superset of SANE C"
« Last Edit: August 08, 2022, 08:17:09 pm by marcov »

winni

  • Hero Member
  • *****
  • Posts: 3197
Hi!

PeterHu asked for the main direction to decide between Pascal and C.

He did not asked for 2^1024 details for his decission.
I tried to get the discussion back to the nitty-gritty

Winni

PS.: On modern machines  the only advantage of Duff's Device is a bloated cache.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
PeterHu asked for the main direction to decide between Pascal and C.

No he didn't: he asked if anything was missing which is a fair question.

I think we've got as far as the ternary ?, omission of parameterised macros, plus the difference in case/switch which- irrespective of the merits of either approach- favours C in versatility.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
PS.: On modern machines  the only advantage of Duff's Device is a bloated cache.

On modern machines, fast moving data,  is a compiler intrinsic translating in to a rep; movs or SIMD move.

And modern is everything after and including Pentium MMX.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
As part of the standard, but could be implemented as pure library solution?

As part of the language. I'm not sure whether than can be implemented as a standard library routine, since a stack (etc.) context switch is involved.

Of course it can be implemented as a library routine, cause that's after all how the other languages do it behind the scenes as well (however they might call that “behind the scenes”). It's just a highly platform specific functionality, but that's in line with some other functionality of FPC (e.g. the Invoke functionality). And there do exist some x86 specific coroutine implementations for Delphi and FPC.

I was not aware that that lazily evaluated?
At least I designed it like that with Boolean evaluation settings in mind.
Suppose two TFunc parameters: then if TFunc1 evaluates to true TFunc2 is never executed because of Boolean shortcut evaluation.
So TFunc2 is Lazy. I believe Michael added an example for it that I added later.

The result type of the IfThen<> function is the same as its if-and else-parameters, thus the function itself will never call any of the parameters you pass in, so you'd have to manually call the returned function variable. Not to mention that the whole usage of anonymous functions would make the whole construct much more verbose than just using a good, old ifthenelse statement.
Other than that there is no lazy evaluation of the parameters of IfThen<> as from the compiler's point of view it's just an ordinary function.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Of course it can be implemented as a library routine, cause that's after all how the other languages do it behind the scenes as well (however they might call that “behind the scenes”). It's just a highly platform specific functionality, but that's in line with some other functionality of FPC (e.g. the Invoke functionality). And there do exist some x86 specific coroutine implementations for Delphi and FPC.

It can definitely be /described/ as a library routine, in the same way that WriteLn() is.

Quote
The result type of the IfThen<> function is the same as its if-and else-parameters, thus the function itself will never call any of the parameters you pass in, so you'd have to manually call the returned function variable. Not to mention that the whole usage of anonymous functions would make the whole construct much more verbose than just using a good, old ifthenelse statement.
Other than that there is no lazy evaluation of the parameters of IfThen<> as from the compiler's point of view it's just an ordinary function.

(Boggle)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
C and C++ have a plethora of different functions to copy strings, while Pascal has just 1.
C and C++ have all kinds of unbounded arrays, even for parameter passing, that Pascal lacks.
Due to the rich macros, you can freely change the meaning of most things and completely change the syntax of C and C++. Pascal doesn't have that, either.

Actually, there are a lot of things you can do in C and C++ that you cannot in Pascal, if you strictly look at the effects. And both cannot do half the things you can accomplish with assembly code. Then again, if you look at the results instead, you see that most of the things that are left out aren't very useful to begin with.

So, is there a program you can write in C or C++, that you cannot in (Free) Pascal? Certainly. There are platforms that aren't supported. But then again, there are also platforms that run Free Pascal applications that have no C and/or C++ compiler. And there are platforms that have neither.

Otherwise, use what you like best, it doesn't matter.

alpine

  • Hero Member
  • *****
  • Posts: 1038
fpc is a superset of C.

If that is even superficially true, please show me an FPC implementation of Duff's Device.

Sure. Just show me a real world application.

P.s. OP probably meant for "FPC is a superset of SANE C"
As long for an embedded, bare metal firmware, I'm using C with an approach similar to the protothreads. It exploits the C switch/case behavior (like in the Duff's device) and parametrized macros to achieve stackless multi-threading.
The lack of similar preprocessor and the different case statement makes such a technique infeasible in FPC.

It is true that with the help of fibers a lightweight co-routines can be implemented, but they're in no way stackless. It's about microcontrollers with a tiny amount of resources, where the protothreads can be the only solution.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
As long for an embedded, bare metal firmware, I'm using C with an approach similar to the protothreads. It exploits the C switch/case behavior (like in the Duff's device) and parametrized macros to achieve stackless multi-threading.
The lack of similar preprocessor and the different case statement makes such a technique infeasible in FPC.

It is true that with the help of fibers a lightweight co-routines can be implemented, but they're in no way stackless. It's about microcontrollers with a tiny amount of resources, where the protothreads can be the only solution.

I think you can do that sort of thing up to a point using SetJmp()/LongJmp(), but the number of issues that somebody highlighted earlier in the year relating to exceptions etc. makes that tenuous.

HOWEVER: somebody made the flat assertion that FPC was a superset of C. I provided an example of something that FPC couldn't do without- at the very least- pretty extreme contortion. End of that particular argument from my POV.

Sticking closely to consideration of the languages rather than the libraries etc., Classic Pascal and K&R C are both grandchildren of ALGOL-60: Pascal via ALGOL-W and C via BCPL. C is actually slightly closer to ALGOL-60 than is Pascal, since Pascal gained the (overwhelmingly important) concept of types.

Object Pascal and Modern C are children of Pascal and K&R C, where C has borrowed more ideas from Pascal than vice versa. As such they are cousins: neither is a descendant or superset of the other.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
DIY: use a timer to push and pop a different set of registers from a list. Done.

If you don't want stacks, use a block of memory to store them.
« Last Edit: August 10, 2022, 03:41:03 pm by SymbolicFrank »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
DIY: use a timer to push and pop a different set of registers from a list. Done.

If you don't want stacks, use a block of memory to store them.

You can't do that within the constraints of either the C or Pascal languages /as/ /defined/.

Sure, you can do it by tacking on assembler or by using non-standard pragmata: but that favours neither C no Pascal so is basically a null argument.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

alpine

  • Hero Member
  • *****
  • Posts: 1038
*snip*
I think you can do that sort of thing up to a point using SetJmp()/LongJmp(), but the number of issues that somebody highlighted earlier in the year relating to exceptions etc. makes that tenuous.
*snip
SetJmp preserves bunch of registers into jmp_buf (sort of context switching) and also some stack space is required. In protothreads the context is reduced to a single state variable.

@SymbolicFrank
It can be given as an example a micro controller architecture/model where the general purpose registers block is comparable in size to the amount of RAM available, thus context switching impossible. AFAIK earlier PICs have a hardware stack with no SP, i.e. not swappable. The Duff's trick works even there.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Yes, like you can change the return address of your function by making a local string buffer and copying one in there that is longer. We call that a buffer overrun. This, too, can be used on micro-controllers to jump from one thread into another one.

Or, you could make a function pointer and insert the address you want, although you could do that in Pascal as well, so that's not an argument, either.

Like, on some micro-controllers, you can use the code as constants, to save on storage space. Or overlap code so you have two different functions, depending on the entry-point chosen. Re-use threads by saving and restoring only part of the registers. Compress and decompress things. Use bits in code words that aren't used for the opcode as flags. Etc. But if you want to do any of those things, you probably don't want the overhead of a runtime and use assembly.

 

TinyPortal © 2005-2018