Any reason to use assembly on the Amiga rather than C?

[Photon]

C++ is also full of nonsense keywords such as void, empty parentheses of different shapes, and lots of declarative nonsense such as

Struct struct = struct;

or anything similar that will make any thinking man squint and blink. It is rather terrible for readability compared to let's say, ideal pseudocode where you break down a problem into constituent parts with as little of the nonsense as you can manage.

But I'm succumbing a bit here to the criticisms of C, which was not my intent. Rather to provide positives from coding in Assembler over C, and I don't have anything to add to what I already suggested.

Main point is have fun coding for Amiga, my friends.

[idrougge]

Originally Posted by grond

Um, I bet the next time you run the program, the Dynamo thingy can just load its stats from the first time it ran the program and doesn't have to wait another two minutes to perform the same optimisations to the same code.

Clang has an option to load a profile from a profiled run of a program and recompile it using that information to reorganise the code according to hot paths identified during the profiling stage. It is not quite as dynamic as a JIT, but allows static optimisation to get closer to dynamic optimisation – assuming your profiling run is close enough to all your users' use cases.

[Karlos]

Originally Posted by Photon

C++ is also full of nonsense keywords such as void, empty parentheses of different shapes, and lots of declarative nonsense such as

Struct struct = struct;

or anything similar that will make any thinking man squint and blink. It is rather terrible for readability compared to let's say, ideal pseudocode where you break down a problem into constituent parts with as little of the nonsense as you can manage.

C++ is a huge multiparadigm language, so yes, it has a lot of syntax. None of which you are obliged to use if all you want to do is write tightened up C.

[Olaf Barthel]

Originally Posted by meynaf

So now C's preprocessor is not C. This means all C programs in existence contain parts that use another language. Preposterous.

For a good laugh, read Peter van der Linden's book "Expert 'C' programming: Deep 'C' secrets". You couldn't make this stuff up if you tried it, because it has already been tried, successfully, between 1972-1973 and no further experiments have been conducted since.

There must be a reason why contemporary 'C' literature (introductory or reference) is what it is: either brief and/or out of print or so large you may wonder whether you bought a C++ book by mistake. 'C' is the perfect combination of weird and useful.

[Karlos]

The fact is, the C preprocessor has it's own syntax and is separate from C, even though it's part of any standard C compiler distributions included tooling. It doesn't understand C itself (though implementations are free to improve upon that) and just operates on the raw text. It will happily mangle C code via macros into something that either doesn't compile, or worse still will compile but just not into what the developer may have expected.

So no, it's not part of the compiled C language syntax. It's a separate tool that's included to make conditional compilation of C more manageable. I've used the C preprocessor to process other languages.

[robinsonb5]

Originally Posted by Karlos

I've used the C preprocessor to process other languages.

Fun fact: if an assembly language source file's name ends with ".S" instead of ".s", GCC will run it through the C preprocessor before assembling it!

(I abused this horribly in the early days of my CPU project because I was too lazy to write an assembler until I was sure the project was worth carry to completion: http://retroramblings.net/?p=1272 )

[Karlos]

Originally Posted by robinsonb5

Fun fact: if an assembly language source file's name ends with ".S" instead of ".s", GCC will run it through the C preprocessor before assembling it!

(I abused this horribly in the early days of my CPU project because I was too lazy to write an assembler until I was sure the project was worth carry to completion: http://retroramblings.net/?p=1272 )

I used the preprocessor to allow me to express MC64K bytecode as something human readable for testing the interpreter before writing an actual assembler. Just don't as what that ended up being written in.

[malko]

Originally Posted by Karlos

[...] as something human readable [...]

Anything can be humain readable as soon as you have learned it. All the different languages that exist on earth prove it everyday.
So you should better say "as something I have learned and understand".

[Thomas Richter]

Originally Posted by malko

So you should better say "as something I have learned and understand".

No, tnat is not quite the point. For assembly, you are just distracted by all the low-level register logic and cannot quite focus on the algorithmic details of a problem. Also "brainfuck" is "human readable", if you are trained to it, but it is still not a practical language.

[Karlos]

Originally Posted by malko

Anything can be humain readable as soon as you have learned it. All the different languages that exist on earth prove it everyday.
So you should better say "as something I have learned and understand".

Sure, you can read a long array of byte values that contains a mixture of opcode values and encoded multibyte values for branch offsets and varying size integer and floating point immediates. I don't think it's quite as friendly as a bunch of function like C macros that generate the same using mnemonic like names.

[idrougge]

Originally Posted by Karlos

Precisely. You cite complications in C from the preprocessor which is just a macro text processor as a defect of the language that is not possible in assembler. That's only true fo assemblers that have no macro functionality at all.

How about an example of where the compiled language after preprocessing stage creates problems that can't happen in assembly language? After all, I can write a C program with absolutely zero involvement of the preprocessor just as you can write assembly without macros.

But we all know that that is a purely academic exercise, both for C and asm. C wouldn't be a useful language without the preprocessor, it does so much that is done in the language/compiler itself in higher-level languages but that was left out of the core C language. To begin with, you can't even include a basic header file without the preprocessor.

One cannot realistically separate C from its preprocessor.

[malko]

Friendliness in reading will vary from people to people.

https://www.protemgl.com/articles/th...-movie-arrival



You can use this keyboard also :

[ Show youtube player ]



Edit : If you have never seen this one : start at 5:15

[ Show youtube player ]

[Karlos]

Originally Posted by idrougge

But we all know that that is a purely academic exercise, both for C and asm. C wouldn't be a useful language without the preprocessor, it does so much that is done in the language/compiler itself in higher-level languages but that was left out of the core C language. To begin with, you can't even include a basic header file without the preprocessor.

One cannot realistically separate C from its preprocessor.

Yes, you can. You can use a different preprocessor or no preprocessor. You just wont be able to compile existing code written for the standard preprocessor. You'd be mad for wanting to do so, but if the preprocessor is so noxious to your sensibilities because it can produce broken and invalid code if you misuse it, you can be a masochist and write a giant single C source*, declare every standard library function and structure you intend to use based on their existing definitions in their respective headers and compile and link it. You will not necessarily be able to compile this on a different target because you forewent the sensible approach of using what is included and the abstractions they use to generalise across implementations.

Of course, writing single gigantic file programs that only work on a single platform is probably water off a ducks back to your common or garden variety assembler programmer. Maybe they'd enjoy C a lot more this way.

*Not strictly required if you don't mind duplicating all your declarations in multiple files.

[Thorham]

Originally Posted by Karlos

Of course, writing single gigantic file programs that only work on a single platform is probably water off a ducks back to your common or garden variety assembler programmer. Maybe they'd enjoy C a lot more this way.

Not a chance Multiple files in both ASM and C is the best thing since sliced bread

[Karlos]

Originally Posted by Thorham

Not a chance Multiple files in both ASM and C is the best thing since sliced bread

As per the disclaimer, multiple files still works.

[Hypex]

Originally Posted by Thorham

Yes, you could, because Bethesda isn't writing it

Which didn't change a damned thing

Who now hold the keys of Doom. ;-)



Speaking of Doom, here's an example. So it's made made clear why C would be used over ASM for practicality to deal with an algorithm. In particular graphic algorithm. And with Doom we see it is written in C and not ASM, though the PC did have coding tutorials in ASM just like the Amiga.


Now the Amiga received several Doom ports. But some has some ASM optimisation. If the C code already existed with a decent compiler, which the Amiga had, then why attempt to rewire the wheel?


Furthermore, and here's a clincher, if at the end of the day C is the best tool for job with compilers like SAS/C then why did they write those chunky to planar algorithms in ASM instead of C? :-?

[chb]

OT: The original DOS version of doom included routines for the texture mapping inner loops in asm.

[paraj]

Originally Posted by chb

OT: The original DOS version of doom included routines for the texture mapping inner loops in asm.

As did quake, and likely every other "serious" game that used software rendering until things switched to using GPUs. More interesting (for this discussion) I think, is that even wolfenstein (1992) used C for most part (though with heavy use of [inline] assembly).

[Karlos]

Originally Posted by paraj

As did quake, and likely every other "serious" game that used software rendering until things switched to using GPUs. More interesting (for this discussion) I think, is that even wolfenstein (1992) used C for most part (though with heavy use of [inline] assembly).

Actually, quake initially had no asm code, even for DOS. That's what Abrash was there for. Almost everything written by Carmack was pure C.

[Karlos]

Just to nitpick, DOS was not the original Doom. It was written on a 68040 powered NeXT system IIRC.