Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: TAK Wiki (Read 25351 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

TAK Wiki

Reply #25 –
Maybe the wiki could be updated using questions and answers from the TAK FAQ topic...

TAK Wiki

Reply #26 –
It looks, as if someone is updating the wiki. Let me say "Thank you"!

TAK Wiki

Reply #27 –
Quote from: TBeck on
It looks, as if someone is updating the wiki. Let me say "Thank you"!


I did some updating last time. Turns out the syntax i had kept was wrong (i had written -4m instead of -p4m for max compression). I also put in the FAQ.

TAK Wiki

Reply #28 –
TBeck: Have you tried compiling your code with gpc (GNU Pascal)?

You might consider not doing the port yourself to c/c++, and open the source in pascal to let others do the port if its worth.

Also, before you release your code, if you manage to make it compile with gpc, binaries for non windows platforms could be provided.
She is waiting in the air

TAK Wiki

Reply #29 –
there'a also Kylix which is the Linux equivalent of Delphi.

TAK Wiki

Reply #30 –
Quote from: Artemis3 on
TBeck: Have you tried compiling your code with gpc (GNU Pascal)?

Quote from: Mangix on
there'a also Kylix which is the Linux equivalent of Delphi.

It's easier said than done. You may read my short explaination here and David Bryant's confirmation. It can't be done within a couple of days.

Quote from: Artemis3 on
You might consider not doing the port yourself to c/c++, and open the source in pascal to let others do the port if its worth.

A big NO, because

- i am convinced, that such an open source project needs a stable and clean code base as reference. IMHO one of the most important reasons for FLAC's success was Josh Coalson's absolutely perfect preparation (Good code, perfect documentation, home page and information politics).

- What if there are not enough interested and good developers who know both Pascal and C?

- Given the code complexity i wouldn't expect the translation beeing performed by one single person. But many people working on this would possibly result in a worse outcome and a not very homogenous code.

There are more reasons, but those listed above are already sufficient for me.

  Thomas

TAK Wiki

Reply #31 –
Just as a curiousity, would you maintain both a C and Pascal version of your code if you made the C port?

TAK Wiki

Reply #32 –
Quote from: prawns on
Just as a curiousity, would you maintain both a C and Pascal version of your code if you made the C port?

No, no, no!

I already find it a bit annoying to care for a C and Pascal header file for my decoding library. And those are tiny pieces of code...

And because of the structural or conceptual differences of both languages it isn't possible to translate source line by line, what  can make things quite complicated. Correction: This isn't true if i first transform my pascal code into something more C like.

TAK Wiki

Reply #33 –
Quote from: TBeck on
I already find it a bit annoying to care for a C and Pascal header file for my decoding library. And those are tiny pieces of code...

And because of the structural or conceptual differences of both languages it isn't possible to translate source line by line, what  can make things quite complicated.
Ah OK, so I take it you'd stick with the C version once it's completed?

Quote from: TBeck on
Correction: This isn't true if i first transform my pascal code into something more C like.
Do you think that if you made your Pascal code more C-like it would still maintain it's speed?

TAK Wiki

Reply #34 –
Quote from: prawns on
Quote from: TBeck on
I already find it a bit annoying to care for a C and Pascal header file for my decoding library. And those are tiny pieces of code...

And because of the structural or conceptual differences of both languages it isn't possible to translate source line by line, what  can make things quite complicated.
Ah OK, so I take it you'd stick with the C version once it's completed?

Yes. Possibly i will still use my Pascal code for the internal evaluation of new compression methods, because it contains many analysis functions which i don't intend to translate to C.

Quote from: prawns on
Quote from: TBeck on
Correction: This isn't true if i first transform my pascal code into something more C like.
Do you think that if you made your Pascal code more C-like it would still maintain it's speed?

Because i wouldn't publish the C-like Pascal code, i will answer the question, if the C version will maintain the speed:

No, i expect it to be significantly faster!

Reasons:

- My Delphi compiler is from 2001. It's limited to i386-instructions and therefore doesn't use any of the sophisticated features and instruction sets of the newer CPUs.
- It doesn't even perform code alignment.
- It doesn't allow for cpu specific builds. Just look at the performance evaluation of different FLAC builds, which can be found in another thread (no time to provide you the link). There are significant speed differences if the proper compiler switches for the CPU have been applied.

TAK Wiki

Reply #35 –
Quote from: TBeck on
Because i wouldn't publish the C-like Pascal code, i will answer the question, if the C version will maintain the speed:
I was just curious if it would it would still be as fast than if it was Pascal like. I don't know if it's possible to make such assumptions until it's actually made though.

Quote from: TBeck on
No, i expect it to be significantly faster!

Reasons:

- My Delphi compiler is from 2001. It's limited to i386-instructions and therefore doesn't use any of the sophisticated features and instruction sets of the newer CPUs.
- It doesn't even perform code alignment.
- It doesn't allow for cpu specific builds. Just look at the performance evaluation of different FLAC builds, which can be found in another thread (no time to provide you the link). There are significant speed differences if the proper compiler switches for the CPU have been applied.
If you can make at any more faster then jaws will be dropping. Can't wait!

Thanks for taking the time out to answer my questions
 

TAK Wiki

Reply #36 –
Somewhat off-topic, but...

I truly don't see the need to convert any good-running program from Pascal to C (or from any language to another language). Too big a danger of botching up something in the non-literal porting.

For you case, Thomas, FreePascal claims that it is able to compile Delphi sources, with processor optimizations.

TAK Wiki

Reply #37 –
Quote from: TBeck on
- My Delphi compiler is from 2001. It's limited to i386-instructions and therefore doesn't use any of the sophisticated features and instruction sets of the newer CPUs.
- It doesn't even perform code alignment.
- It doesn't allow for cpu specific builds. Just look at the performance evaluation of different FLAC builds, which can be found in another thread (no time to provide you the link). There are significant speed differences if the proper compiler switches for the CPU have been applied.

Delphi 6 was released in 2001. Borland Pascal compilers are generally well optimised, I am not sure new instructions (other than SSE2 etc) would help much.
For code alignment, try {$CODEALIGN n}?
http://www.freepascal.org/docs-html/prog/p...#x14-120001.1.7

TAK Wiki

Reply #38 –
Quote from: jido on
Delphi 6 was released in 2001. Borland Pascal compilers are generally well optimised

So far i can agree...

Quote from: jido on
I am not sure new instructions (other than SSE2 etc) would help much.

...but here i have to contradict. There are many possibilities for cpu specific optimizations, which DELPHI's "one compile fits all" can not adreess. I have looked at the assembler instructions of the DELPHI generated code and i have found many possibilities for improvements.

SSE2 is a different matter: I don't expect significant improvements without hand optimized assembler code. The same was true for my MMX code.

BTW: If i say significant improvements, i am talking about speed ups of about 10 percent, mainly for the presets TURBO and FAST.

Quote from: jido on
For code alignment, try {$CODEALIGN n}?
http://www.freepascal.org/docs-html/prog/p...#x14-120001.1.7

Unfortunately the Delphi 6 compiler doesn't support this... I had to perform some dirty tricks to achieve code alignment for at least the most critical code parts.

TAK Wiki

Reply #39 –
I was looking over the recommended settings and commented over at the "TAK(ing) with EAC" thread.

Please have a look:
http://www.hydrogenaudio.org/forums/index....st&p=489302