Where is the LIGHTSPEED?

[funkheld]

Hi good afternoon.

Where is the LIGHTSPEED?

Thank you.

greeting

[Justin Payne]

Why, it's right here, silly.

https://atariwiki.org/wiki/Wiki.jsp?page=C

[+Larry]

But more like impulse power than warp...

 

-Larry

[Timothy Kline]

Has anyone put together a comparison review from a programmer's perspective of the "C" languages for Atari 8-bit, going over their respective strengths and weaknesses as well as their relationship with modern 'C' ?

 

I've never ventured into C, but since it seems like something that can be carried forward into contemporary programming on PC or Mac (?), it does have me curious.

 

Thanks, in advance!

--Tim

[Justin Payne]

Yea, I always wondering how good those old compilers were. I suspect they weren't that good but one could write specific benchmarks to test em, like these. http://benchmarksgame.alioth.debian.org/. Of course, I'd also want to test it with a cross-compiler which, I suspect, will do the best job at it.

[Tillek]

I've always been interested in which languages did the tightest/fastest code. Been looking to get back into some development but alas, I'd have to set up a dev environment of some kind... don't even know where to start right now.

[Justin Payne]

I've always been interested in which languages did the tightest/fastest code. Been looking to get back into some development but alas, I'd have to set up a dev environment of some kind... don't even know where to start right now.

Well, it might be fun to take that code that is made available on that page and adapt it for each compiler. The run em to see which is faster. That shouldn't be that hard.

[VladR]

I've always been interested in which languages did the tightest/fastest code. Been looking to get back into some development but alas, I'd have to set up a dev environment of some kind... don't even know where to start right now.

For this effort, if you have a C compiler, start with no optimization switch, examine the binary via disassembler, and then repeat for each optimization switch that the compiler supports.

 

While usually nothing beats the hand-optimized assembly, when you have a more complex CPU (say, a RISC), then a compiler may actually make a better job, as it can go (brute-force) through all permutations of rearranging instructions (to improve interleaving).

 

 

From my experience, the fastest way to get something working is to use a high-level language and just write the time-critical parts in assembler. The best IDE/language that I found that supported inline assembler was TurboPascal 6.0 on 80286. You wrote all your basic code in pascal, and then simply inlined ASM for performance-sensitive features. It was amazing - you got best of both worlds:

- quick prototyping for base infrastructure of the code in Pascal

- once the shit was working, you just inlined assembler for the rendering (or other performance-critical) functionality, right there - in the middle of your pascal code (or, you could write asm-only functions)

 

This way, you get something up&running very quickly, and then only focus on optimizing (ASM) on what needs to be optimized.

 

 

Not sure, if there's any language/IDE like that available for Atari 800, though...

[Justin Payne]

Well, right off the bat, Lightspeed is going to make it difficult to execute those benchmark tests since it doesn't support long and shorts. Still, might be a fun but I think a table of supported features might be the first step.