Is it possible to program Raspberry Pi in assembly?

Well, my title may seem kind of stupid, of course it can, it's a computer, but the main question I have is if I have an assembled program on an SD card, plug it into the Raspberry Pi, will the bios load the assembly program into RAM and execute it as if it were a bios? If so, is there any documentation on the memory architecture and such anywhere online? I'm doing a school project with it and I don't feel like learning C or such. Of course, I don't know if it would be easier to use a language I already know but have to learn the hardware, or learn a new language and not have to learn about the hardware. I hope this topic isn't too off topic for this website, and if it is, feel free to call me out. Anyway, thanks for your help as always!

Well, your terminology is slightly off, but sure, of course. What do you think the Pi does when it loads Linux or whatever other OS?

That's great, is there any documentation though? Kind of like the TI-83 Plus developer guide? Which I'll link to here:https://education.ti.com/en/guidebook/details/en/830D08FF31804AEAA2F03B8F5E89AD14/83psdk

The Raspberry Pi boot process looks like this, involving a couple files that run on the GPU before kernel.img (the ARM executable) is even loaded. It's a lot like the Wii, where the I/O processor does its thing (boot0, boot1, boot2, IOS80) before booting the main PowerPC CPU.

The GPU is heavily proprietary.

I can't find any assemblers, only C++ and C compilers on the ARM developer website, I'll leave a link to it here: https://developer.arm.com/products/software-development-tools/ds-5-development-studio It doesn't say anything about assembly language. Is it just that literally nobody uses assembly language anymore? I'm basically just using assembly language to avoid having to use any higher level languages because I personally find them way to complicated for my taste.

I promise that it will be much easier to start off by writing assembly user-mode programs that run under linux, instead of supplanting the entire kernel.

(Replacing the kernel isn't that hard of a second step, but it is a bigger step)

If it's just a gcc cross compiler, binutils (which has an assembler) will likely be in there somewhere as it has the linker.
You could also compile binutils yourself targeting arm.

I can program basic kernels like a game engine for the NES, and that's really all I'm doing, I'm just programming an Atari 2600 emulator that runs off of real cartridges.

You can just look up the CPU to learn about the instruction set. All that stuff is well documented.
http://infocenter.arm.com/help/topic/com.arm.doc.den0024a/index.html

As far as whether people program in assembly "anymore", yes sometimes, but not a lot. The usual reason people used assembly in the past was for efficient performance, but the potential to hand optimize in assembly has diminished a lot. Compilers are better now than they were in the past, the CPU has design considerations that are suited to modern languages, and on top of it being able to optimize involves efficiently using 32 general purpose registers at once, while navigating deep pipeline issues and multi-level caching. A good compiler can handle this stuff pretty well already-- a careful human can always do better, but it takes a very slow and steady hand.

If you're expecting the experience of writing assembly for modern ARM processors to be anything like writing NES assembly, you're probably in for a rude awakening, but go for it if it interests you.

If you want to code assembly and have bare metal access to hardware, try the GBA or NDS.

Somewhat simple example. I think it might actually use libnds so it doesn't exemplify hardware access very well, but it shows you the bare basics behind setting up an assembly project for DS.

You do not need to care about any of this when programming in assembly for the ARM (at least not the ARMs I have myself programmed in assembly - perhaps more modern ones are different ?). You can just ignore those issues unless you absolutely want maximum performance, which you typically do not care about 99% of the time.


I wonder wether gcc is one of those "good compilers", or if they just made it "just work" with minimal care about hardcore optimisation. I'd lean toward the second possibility, considering it's free.


Then do yourself a favour and do not learn C. It's bad as a low level language (assembly is better), bad as a mid level language (Pascal is better) and bad as a high level language (Python is better). The more I think about it, the less I see any advantage of using C at all. The only reason it's used is because Unix, and later it's close Linux, used it.

If you learn any of the curly brace languages (C, C++, C#, JavaScript, Java, etc...), you pretty much learn most of the other languages at the same time. Just that each of these languages has oddities that set it apart from the others.

You will probably need to make a few posts on this forum https://www.raspberrypi.org/forums/view ... e7bf70b603

While Atari 2600 people call the part of their game engines "the Kernel", that is a very specific naming thing only to them, and a Raspberry Pi Kernel is not a couple of things that change 3 registers to make X happen. A Pi Kernel is going to be a few hundred thousand lines of code, and well ARM asm is verbose. You will have to set up the CPU, create the vectors, stack, init all the registers, set up the timings, talk the peripherals, init RAM, make a SD card reader, a graphics driver, a USB host driver, and then be able to talk to what ever your input is, unless you are using GPIO and DB9 joystick to which you might be able to skip the USB code.

GCC is a phenomenal compiler/optimizer. It's not quite as good as ICC, but is as good or better than pretty much everything else out there. It's industry standard for a reason. Per Wikipedia:


I promise, tons and tons of work (often paid) has gone into optimization in GCC.


I mean, for this particular project maybe, but in general no: do yourself a favour and learn C. Regardless of its quality or lack thereof, it's one of the lingua francas of the programming world and there exists a huge ecosystem of tools/libraries around it. It's small and relatively simple (crazy corner cases excluded), so it's quick to learn; the ratio of benefits you get to the amount of time you put in is enormous.

Why is it that getting a kernel on the Raspberry Pi is way more complicated then say, the NES? They're both computers, is it because the Pi has a bios? Of course, on the NES I control hardware like the controller ports, PPU, and the APU, why is the Pi so special?

It takes more code to drive a system-on-chip (SOC) that does more stuff. USB is much more complicated than SPI, SD storage is much more complicated than a simple execute-in-place (XIP) ROM, 3D graphics is much more complicated than 2bpp tiled backgrounds and sprites, HDMI output is much more complicated than shortcut-filled composite output, and provision for battery power is much more complicated than assuming a wall wart provides power that's too cheap to meter.

the BIOS is the Kernel.

So the nes has an 8bit cpu single core, connected to a simple 8 bit graphics chip, you have what ~32 registers to init(not counting OAM RAM and attributes etc) , and everything is executed from ROM, and has SRAM.

The Pi has a quad core, 64bit CPU, that dynamically adjusts it clock frequency based upon thermals so it doesn't destroy it self, a 3D GPU, can only execute data from RAM, which is DRAM and needs a refresh system, cycle and warm up, you have to detect which output format you are using, Composite, HDMI, 480i, 480p, 720i, 720p, 1080i, 1080p, 1024x768, 640x480, 640x400, 800x600, 1920x1600 and set up the graphics buffers, allocate VRAM, program the vertex and pixel shaders, init the ABI, init the multiple peripherals, deal with the complicated timings, structure and formats of the external devices, detect, setup and get the IDs for any connected USB devices, parse their headers and formats and set up interrupts to handle their data... basically the NES is a bear bones simple piece of hacked together dodgy hardware made with sticky tape and the Raspberry Pi is good few 1000x more complicated.

A 6502 says my stack is 256 bytes and its at $100 no if no buts, no virtual memory and no cache. The Pi has a stack per thread per core, and it can be where you want it to be, and that works thanks to your virtual memory system that abstracts and caches data to/from the internal caches and DRAM and patches up the addresses for it.

So hen you say the bios is the kernel, are you saying that the bios does all that so the programmer doesn't have to? Or do I still have to do that.

The BIOS will get you part way, excatly how far I don't know, what is and isn't in it changes over time and what model Pi you are on and which OS you are using and its been a while since I booted my PI. It will probably get you a code entry point and set up the basics for the CPU and GPU. However output resolution and the like is probably an OS Kernel thing and not a BIOS Kernel thing. The Pi will have multiple layers, Boot BIOS, BIOS, "Kernel mode"Kernel and Userland Kernel. If you look at the Bare Metal forum there are people who have made small setups and systems that will get various features here and there(terminal access, GPIO access, SD card readers, USB keyboard driver etc ) which might be enough for what you want. But honestly don't waste your time on it at the moment, and just make a Rasbian elf and modify the linux boot script to call it upon boot, and focus more on making your game then spending 3 weeks looking at Rx/Tx terminal trying to work out why it doesn't send an A back. Once you have the game get it working bare metal, that way you will be able to make the call on what you do and don't need, and being able to step through code in a debugger makes life a lot easier

The NES has quite possibly the simplest programmer's interface in a mass produced full-featured computer (by which I mean "a device with input from dedicated multikey input device and outputs to a screen") to ever have existed.

With only 30ish total configuration registers to describe its total functionality, various Dubious Choices are practical (such as Bregalad's insistence that it is obfuscatory to name those registers instead of just using addresses) in ways that would be laughable on practically every other computer.

The 2600 has drastically more registers (roughly twice as many). DMG, roughly three times as many. The SNES has close to ten times as many (although the majority are part of the S-DSP). A modern computer will have thousands, often hundreds for each individual component.

The IC that controls my monitor (converting DVI to LVDS) has several hundred.


The RasPi has the additional problem that it's actually an ARM core running on top of some magic being done by the GPU. Exactly what, we don't know, but there are people who have been trying to make a FOSS reimplementation of that blob.

Yes, but I was explaining why assembly is uncommon for this platform (RPi). If it's for optimization, it's normally not used much.

Someone who wants to write in assembly because it's their favourite thing to do is an outlier. These people do exist, but it's generally only applicable as an obscure hobby. In a professional setting you would not normally be allowed to do all your work in assembly without some very good justification.


GCC is one of the very best, and though it is free and open source it has been professionally maintained for decades now.


Over my career, I'd estimate 90% of the work has been C++, 10% other languages. Different languages are popular in different application domains, but C++ is very widely used, and very productive language. I don't think it's a "favour" to obstinately ignore a popular language; knowing C++ has literally been worth hundreds of thousands of dollars to me. (For anybody that's about to make a pedantic distinction: knowing C is a good stepping stone to learning C++.)

Python is very worth knowing as well; widely used and productive in appropriate applications. Surprised by the suggestion about Pascal, but maybe you operate in circles where it is more commonly used. I'd definitely learn it if it was in my path. I can't think of a programming language I've ever regretted learning.



Heh, I also feel that the numbered address is the easier to read and remember for NES registers.

I too learned C before C++, but not everyone agrees.

I know already, I meant, I don't know if it accounts for internal pipeline when ordering instructions. In any cases it doesn't matter all that much, except in very rare cases.


I still admit I never understood how free software of such a big scal was economically possible in the 1st place.


If he had interest in C, I'd agree with your advice. But he said explicitly he does not have any interest, so I confort him in that it's fine to program using other languages. I am not so much against C than I am against the thought C is everywhere and should stay everywhere. The only reason C is so popular is:
1) It's popular (aka snowball effect)
2) It was used for Unix and Linux programming

The language itself, while decent, is far from great, and technology had made decades of progress since the late 1970s making C largely obsolete.


Do you account countless time to understand extremely obsure 10-pages long messages form the linker in your measurement of "productivity" ?


Well that's great for you, I haven't been so lucky. By the way, considering how insanely complex C++ is, especially the later 11 and 14 versions, by "knowing" it do you do like me and pretend knowing it because you can use it to make your programs, or did you dedicate 10 years of your life studying the dark corners of this language ?


I'm in the process of learning Python those days. This makes me never want to code in C++ ever again, (and probably neither C, although it's not as bad because at least the feature creep is limited). It really shows how it's better when they thought of the language as a whole from the start instead of piling up new features on existing grammar that was never meant to support them in the 1st place.

Couldn't agree more.


Sorry, but C is big and complex. It needs header files, pre-processor, compiler, linker, when many interpreted languages can just get your code working in a bang. It's harder to debug than most languages. The support for error handling (or the lack thereof outside of errno) is downright awful. It creates more limitations that aren't even there in assembly. For example strings have to end with NULL, when in assembly it's not the case.

Memory handling is very complex. Pointers and arrays are handled in an awfully confusing way. None of these problems exists in most non-C family programming languages.

The reason I chose assembly language is because I assumed that making a window we be like WinAPI, which is way more sophisticated than I can understand. Is Linux not like that? I just don't like how different all the higher level languages are with all their data types, arguments, etc. I thought that assembly language on the raspberry pi would just be writing the 24-bit pixel to the screen. I find libraries and all that a pain in the neck, especially external libraries. How does it know where on the hard disk to find it?

Modern framebuffers often aren't linear in-order chunks of memory anymore.

You really want to use SDL. I know you think you don't want to rely on external libraries, but I promise you that you're definitely choosing a more difficult path for no greater result.

I couldn't agree with bregalad any more, I hate how C has weird syntax, with the ; character and curly brackets and so many other random instructions that just shouldn't be part of the language in the first. I like assembly language, especially 6502, because it has no more instructions then are absolutely necessary, making it easier to remember every instruction, and probably the most simple syntax there is, you have an operation, then a memory address or value, and occasionally, a little ,x for indexed addressing. It would have been nice if we had a compiler version of BASIC like on computer from the late 70s through early 80s. But honestly, I kind of regret that I went with programming on a game console that's over 30 years old and nobody cares about rather then learning C, a language where I can actually get a job off of. But if there is one language that I think that people from assembly would hate, it would probably be Java...

Pfft, the 6502 is bloated. 56 instructions? What you really wanna learn is an OISC assembly language.

Which is to say, it's actually too small and simple. Your interpreted languages have many more moving parts, and scary levels of them in order to get comparable performance.

Once again, you're actually arguing that C is too small and too simple.


I don't know, maybe there's actually an interesting point to made that C is the "unhappy medium", too many abstractions over the hardware for...something... but simultaneously too few abstractions to make things easy.

But I'm about 99% certain that that position is indefensible.

Wtf?


How are they then? I thought a framebuffer was just a giant area of memory with each row of pixels onscreen being at a different offset in the framebuffer.


I didn't count, but I'm pretty sure the S-CPU and S-PPU1/2 have about 100 registers between them. Why does the S-DSP have so many?

Often, it's tiled. Each square region of memory is rasterized in order in itself, and spitting out a scanline involves jumping around between tiles.

This means that they can use the exact same hardware for VGA/TMDS/LVDS/MIPI playback as they use to blit polygons.

8 channels and 11 parameters per channel goes pretty far. Plus another 15 DSP parameters for global settings and 12 more specific to the SPC. So 115 total there, plus ~60 for the PPUs, ~30 for the CPU peripherals that are NOT the DMA controller, and another ~90 for the DMA controller ... roughly 300.

Yes, of course. In all programming tasks you have to deal with errors. That's part of the work.

When I say productive I mean people successfully use it to make applications all the time. You can make stuff with it, and there's a large workforce constantly doing so. Whether or not it's the theoretical "best" language is mostly a worthless debate to me, but whether it's a practical one for getting a project done is not at all.

C++ has linker errors, and sometimes they're cryptic, especially when you're inexperienced. Is there some programming language that magically never has cryptic errors? Do you think python runtime exceptions are easier to debug? (I do not.) With a little bit of experience you get used to errors and how to cope with them. Difficult linker errors happen, but with some practice you begin to understand how to solve them and how to avoid them. They are typically a bit of a problem when doing initial setup for a C++ project, but hardly ever a significant amount of ongoing work as it continues.


Ok, so maybe putting a ballpark figure on it was a bit over the top, but in terms of 10 years salary it should seem reasonable?

More or less I've been working professionally for 10 years, using C++ on a not quite daily basis. So in that respect yes I've spent that much time studying the language by now, but I hadn't when I started. (I think I'd been using it unprofessionally for another 10 years before then, but I'm not sure how focused that effort was; it was not my primary occupation until then.)

My point was that knowing C++ puts food on my plate. There's a lot of companies right now that need people who can use C++. You don't have to be a 10 year expert to start a job. The major stuff does not take 10 years of study, the rest you can learn incrementally over time as it comes up.


And back to the topic, I was really just trying to express why you won't find a lot of people writing assembly programs for RPi:

• Most people do not find assembly "easier" than higher level languages (though this board is full of exceptional people in that respect)
• The traditional efficiency reasons that made assembly dominant 30 years ago do not apply now

I only advocated for C++ as a counter to the idea that someone would benefit from avoiding it, which I disagree with.


As a learning project, trying to do assembly on the RPi is feasible, but very unusual. You're probably not going to find tutorials on the subject, because very few people are doing it. I think you'll find most people are usying Python on it, actually, but what I'm trying to get across is that it will help you learn a lot if you pick something there's an established community of people doing already. Forcing assembly onto this goal will require you to be a lone wolf.

For example, the only instruction in a transport-triggered architecture is MOVE. This means its ALU is memory-mapped, not unlike the multiplier in an MMC5 or the multiplier and divider in the S-CPU, letting an engineer customize the ALU without having to customize the core control circuitry. But then watch a 6502 fan write a macro pack that calls moves to and from the ALU's accumulator port LDA and STA and invents an instruction name for the move to each operation's second operand port.

I didn't actually learn C before C++, technically, but I don't think learning programming languages is a linear process. I strongly disagree with the premise of that lecture you linked that learning C first retards or corrupts your learning of good C++. Good OOP practice can be learned before, after, or in tandem with C, and these skills take take time and effort to acquire. Being a bad C++ coder is a step in the process of becoming a good one, and every language you learn helps learning others in some way.

Oh... yeah, I'm an idiot; I didn't take into consideration that every DMA channel has its own copy of registers, so yeah, I can see the S-DSP taking the majority.


Interesting... Is it in squares for VGA/TMDS/LVDS/MIPI for (lossy) compression of the signal? If it isn't evident by now, I really don't know what I'm talking about.

In hindsight that's pretty clearly 40% for APU, 40% for CPU (DMA is part of the CPU), 20% for PPU. But my point was really "SNES as a whole has 10x as many as the NES", not "The APU by itself has >5x as many registers as the NES" (and anyway it has actually ≈4x instead of >5x)

I don't actually know. I think it's because there was a decision to move the video scaler from inside the monitor to inside the GPU. (In a laptop, the boundary was already super fuzzy). Treating the output stage as a special case of "draw a scaled polygon" means that you can easily handle rotation/scaling/keystone correction at an earlier stage, and hopefully result in higher quality.

Well, yeah.


I'm assuming this never actually took place, because I've used TVs with such underpowered processors that it feels like there is a third of a second of input lag. What kind of hardware does the average 1080p TV have, or would it vary to much to accurately guess? Is it just some off the shelf ARM processor?

It's just bad programming with too many buffers and pipeline steps.

What? It's in every laptop. Probably most cell phones. As a result, it's in your desktop GPU also, because laptops are where the volume market is.

Whatever flat panel LCD monitor you have probably has its own scaler also.

While it's possible that the device inside your television might use an older style in-order framebuffer, honestly the lag is there because they have no reason to avoid it. It's simply not something that's important to the mass market. And it does let them do some limited acausal image processing, which they think looks/sells better.

I'm going to say the C64, while it does have more registers at 110, it also has a Kernal which will set up the machine to a known state and then let you take over if you want, or you can go purest bare metal and do everything yourself, or just call the Kernal when you need it. Everything is in a flat memory model, there is no you need to write this register twice to make it set some hidden internal thing, no magic write to this register and it will DMA sprite data to and from here, no separated memory model of CODE here and PPU data over there and you can't see it. Everything is in the CPU space and you can change whatever you want whenever you want. And it has built in Character Font.

oh please... Python is a "oh look a shiny lets chase it" language if I ever saw one... I mean to be clear here which Python are you learning 2.x or 3.x ? now is it append on a list adds the items in the list to the list or is += that does it, or do you append if you already have it in a list but += if you don't have it in a list to make sure it gets added as a single item into the existing list? The Class is a tack on, not really a feature of the language its more "we can abuse this to do X", enums are hack of a hack, isinstance is a global function not a member function, len is also a global. How do you make an iterator, you just throw an exception when you are done... so if you want to trap exceptions to find a bug well you get one every loop because somebody decided to use an "exception" for something that is a foregone conclusion and also the whole programming paradigm of the language...

c++17 still builds c++89 get new version of VS or GCC hit build carry on Yes C++ has some tacked on things, metatemplates for example. but you can easily just ignore them and carry on.

This is true and not true.

PowerVR based GPUs use "tiled" rendering, this means the GPU makes buckets and once a bucket has enough changes it will then process that "tile" and update the screen. This allows it to save on power, which is nice for batteries and for Thermals. So anything that is basically a mobile phone has this type of GPU, the Pi is basically a like a mobile phone. the Dreamcast has a PowerVR GPU and the PS2 has a similar architecture and its like lots and lots of little triangles.

On a windows PC with a Geforce anything... its has the bandwidth, thermal and power that you can just throw a 1080p linear frame buffer down the bus each frame and be done with it.

Most of the S-DSP is actually a matrix, 8x10 registers which are identical for all 8 sound channels. Only a handful of registers are common to all channels, and many of those actually have one bit per channel. Ignoring the dupplicate between sound channels, the S-DSP has maybe 20-30 registers at most.


I fully agree with this statement. C is not useful to do anything high-level quickly. And it's not good at optimizing for hardware level either - the only reason it optimizes to decent codes is because HUGE amount of effort went into doing this, not because the language facilitates it.


I am not yet experienced enough in python to answer, but so far the errors were a stack trace with the exact line of where the error happened, with a comprehensible error message. It would be hard to imagine anything more practical.


Well that's great for you. If my boss, or your boss, or anyone else's boss, asks for a project to be written in C++ because it's a project requirement or whatever reason, that's fine. I wouldn't care having a job where I had to code in C++ only, if I'm being paid. However, we're talking about free time, homebrew project. There's zero reason to force you to use a painful language just because it's used in the industry - at home you're doing this for fun and want to maximize the efficiency you get out of your sparce free-time. C++ is a poor choice in my opinion, here, but if you're using it at work it helps you to be fluent because of habbit - but rememer, it's not the case of everyone else !


I'm learning 3.x, and also, I never pretend Python was perfect or anyhting, just like it fixes a LOT of problem C++ had. I lack experience to juge the language, maybe I'll come some time later saying that it's a piece of shit, I don't know. At first glance it looks infinitely superior to C++, getting rid of limitations that were imposed by the language for no real reason other than backwards compatibility with the earlier C, which in itself came with many issues.

The fact 3.x is not backwards compatible with 2.x is actually a good thing and show courrage from the development team actually. C++ is bad because it's a pile of stuff designed with backwards compatibility in mind, in the end it becomes too messy. By admitting "we've handled it wrong in 2.x, let's fix it", they restart anew and don't keep things the wrong way.

There aren't subtle differences like on the 2A03 APU, whose sweep unit's carry behavior differs between its two pulse channels, are there?


Until an employer decides whether the skills you show are a good match for a position by looking at what technologies are used in your hobby projects with source code published on Savannah, GitHub, or SourceForge.


I think a lot of the hate for 3.x was because 3.0 through 3.2 had no easy way to share a Windows PC with 2.6/2.7. Side-by-side installation of Python 2 and 3 was practical on a FreeBSD or GNU/Linux PC, as those use #!/usr/bin/env python3 at the top to specify a Python version. But Windows associated the .py and .pyw extensions with only one interpreter. This was fixed with the implementation of PEP 397 in Python 3.3 and later, where .py and .pyw are associated with a shim program py.exe that looks at the first line of a file to determine which interpreter to run.

As far as I know, the only difference is that the first channel (I don't know wether it should be called channel 0 or channel 1) cannot have pitch modulation.


I do not think knowing C++ and being proficient in another language is worse than being proficient in C++ only. The fact your tools are related to gaming is probably a worse signal than the language you use to write them.

Arguing that C is not good for "optimizing things for hardware" requires being willfully ignorant. Generating machine code for a modern computers is a huge broad optimization problem and this is not something that possibly can nor even should it be expressed in the programmer's language itself.

Or are you seriously going to argue that the varying size of an L1 cache line from microarchitecture to microarchitecture is something that the programmer should be forced to think about?

I didn't state otherwise.


I never said that.

Then justify your argument that "[C is] not good at optimizing for hardware level either" as a meaningful statement with something to contrast against, as opposed to just a useless statement of opinion.

What I meant is that, when I started programming in C I was tricked into thinking that if I wrote programs a certain way it made them optimized, when it fact I couldn't be further from the truth.

For instance at first glance you'd think that:

will use the "inc" instruction and be more optimized

will use the "add" (or watthever) instruction. But actually, it's completely wrong, the instruction used has nothing to do with the C code and the ++ operator is basically completely useless, they might just as well not have it in the language at all.

Similarly, you can think that

uses the zero flag and is faster than

But actually it has nothing to do with that, and this doesn't make any difference, so you might as well use the verbose, explicit comparison and make it clear what your code is doing.

The "const" keyword will make you think it helps the compiler to optimize the code, by putting things in ROM instead of RAM, or by avoiding useless copy of data. Actually it does none of this and this keyword is useless when it comes to optimization. Any data with "const" keyword is still writeable, just not through the name you're declaring.

The ANSI C standard requires all operations to be performed to at least 16-bit ints by default, killing any hope of getting a decent performance on any 8-bit CPU.

Another problem is how arguments are passed by value, killing many optimisation possibilities, especially when passing large object. You need to either pass a pointer (wastes resources) or copy the data to the stack (wastes resources) or use C++ and the tedious "const& " all over the place. I know in some cases those copies can still be optimized out, but only at the price of a major effort from the compiler and full control-flow analyzis of what your program is doing, definitely not thanks to the language.

Because access to types are explicit, it kills optimizations that the compiler could do without telling to improve performance. For instance, in 6502 it's common to store LSB and MSB of arrays in two separate 8-bit arrays. C could never achieve such an optimisation, because arrays of 16-bit ints are explicit to the user and accessible with pointer arithmetic. When higher level languages such as Python (or any other langauge without explicit pointers) COULD optimize it that way.

Just the examples I thought off, there's probably a lot more. So there's nothing wrong about C but it forces you to avoid some optimizations, and make you think you're optimizing code when you're not.

Your argument seems to boil down to the tautological argument that because C is not machine code, C is not machine code...

But knowing the underlying machine code doesn't tell you anything about whether that code would perform well either!

The x86 LOOP and JCXZ instructions used to be preferred (higher performance) ways to construct loops. But modern machines (really, everything since the pentium) they're slower than doing the loop using generic instructions instead.

If C had given you the ability to say "no, I want to use the INC instruction instead of an ADD instruction", it'd be giving you an even greater way to shoot yourself in the foot than just memory management. It'd be a portability nightmare, comparable to actually rewriting machine code instead of a useful language.

Did you know that x86-64 deprecated several instructions altogether? The byte 0x40, which meant "INC (E)AX", is now used for something else. Other architectures don't provide an INC instruction at all. Why do you think this is something the programmer should be thinking about?

You're getting a bit ridiculous here. "Painful language"? I use C++ in my own hobby stuff because I like the way it works and what it can do.

Give me a break.


No, to be optimized it should use whatever method of incrementing is most efficient or practical for the situtation, and that what it does.

I think you're mistaking "optimization" for "direct control of assembly output".

I'd agree ++ is not a great feature, and I think it's a little bit vestigial, and there's actually something in it very worth complaining about (e.g. prefix/postfix side effects) but in general it's very easy to use and completely normal to understand.


Again, it does use the zero flag when it's efficient or practical to do so. Again, this is not an optimization concern, but an assembly output concern.

C actually usually has inline assembly built into the language for addressing that kind of concern if you need to. (MSVC has started to phase it out with its 64-bit compilers though, in favour of other techniques.)


Not really true. On a platform that has ROM, or can write protect memory, const data very often does go somewhere that is phyiscally made read only.

In some cases you can't protect it in that way, e.g. a const temporary on the stack. Attempts to assign it to a non const pointer are a type safety violation and the compiler will stop you. You're allowed to explicitly override this, but in that case you're deliberately sabotaging yourself.

There is the problem that direct memory access is not prohibited in general, and the most often source of errors with this comes up because of how arrays have no bounds checking (e.g. buffer overflow attacks).

Of course in C++ they added mechanisms that provide bounds checking for arrays, so that problem is already solved if you're not obstinate about it.


No it doesn't. Maybe you're thinking that the default "int" is going to be 16-bit, but if the result is going back into an 8-bit type the compiler is by no means required to do any 16-bit calculations at all.


Okay so you just described that you can pass by value, by reference, or inline. What is the other optimization possibility that is being killed here?

In a lot of other high level languages you don't even have options about whether something is passed by value or reference. Java in an example that bothers me, where you primitive and object types are passed in different ways without any syntactic difference. Python on the other hand has types that are implicitly mutable or not and often you don't find out which until a (cryptic) runtime exception occurs (e.g. is this a Bytes or a ByteArray?).



C can do this through macros, to some degree.

C++ actually can do this efficiently and effectively though.


Anyway, I honestly find this nitpicky attack on C really strange. What are you comparing against? Is there a language that you use all the time that you really don't have any qualms like? Everything here you've picked on was either trivial or wrong. If you named any language I could say a thousand similar things about it. What's the point? They've all got some problems, but well used languages have plenty of good ways to cope with those problems (i.e. practice effective coding styles, and learn the ropes).

I've read through a lot of books and tutorials on languages in the C family, and they were all only about making command line tools, none of them mentioned anything about plotting pixels and creating an actual window for my program to run in. What is the WinAPI for Linux like?

There are many options (raw X calls, XAW, TK, GTK, QT)...

but for what you seem to want to do, you should use SDL.

itt: a guy who hasn't completed his game in ~13 years arguing with a guy who hasn't completed his game in ~4 years over which language is most effective to program in

really jogs the nog

use whatever the hell language works for you. if you latch on to C, use C. If you latch on to Python, use Python. doesn't matter what you use so long as you're using it. really, the bottleneck is not the language but willpower and the motivation to learn of the person using it.

also, this whole language wars shit got old 30 years ago. stop wasting time on it and go outside or something


SDL2 library. SFML if you're doing C++.

Why would you even say this?

I'm in a rude sour mood today and hoped a cheap shot would put an end to your two arguments.

My point was, it's foolish to think the choice of programming language is a magic bullet that allows one to work faster/better or produce better code. Or text editors. Or operating systems. Or gym equipment, et cetera. The difference is negligible compared to human factors like motivation and perseverance. A lot of time is spent arguing about programming languages but in reality it's all for naught.

I know you and Bregalad mostly weren't really talking about this. It was mostly you correcting his misunderstandings and such. So don't take what I say too seriously; I'm just shitposting cause I'm grouchy.

You may have had an argument there if either game was actually programmed in any of the languages that were being discussed.

It's still true, but compilers nowadays are smart enough to see the easy ones like ++i; versus i += 1;. There are still things that can trip up a modern compiler. For example, indirection via pointers is harder to optimize (because the compiler can't always prove you're not modifying the pointers you're using), so you can gain some speed by reducing indirection. Of course, you should only worry about that after you've come up with a good algorithm. I don't think any compilers are smart enough to replace a slow algorithm with a fast one.

I know it's already been mentioned, but on modern CPUs the ideal instruction for a given operation is often not obvious. On some x86 CPUs, INC can be slower than ADD, and the compiler will take this into account when it generates code.


Converting a pointer to a non-const object to const and then back to non-const is defined behavior: since the object is non-const, then any non-const pointer to the object may be used to change its value.

Converting a pointer to a const object to non-const is undefined behavior: the compiler assumes that your program will never do this, so the results will depend on how the compiler decided to optimize the const object. It may behave as if it were never declared const in the first place, or it may behave as if it's constant sometimes and not other times, or it may truly be constant, or attempting to change its value may crash your program.

Declaring an object as const doesn't prevent you from writing, it tells the compiler that it should assume you will never write. How much of a difference that makes depends on the compiler.


This sounds more like a problem with cc65's optimizer than anything to do with the C language itself.


The 6502 is very limited compared to the minicomputers C was originally used with. It's unlikely anyone involved in designing C or the 6502 intended the two to be used together.

The point of C is it doesn't matter if I do
i++
++i ( in a single line non-assign case)
i = i + 1
i += 1

because the compiler will just work it out for me and do the hard work of caring what is the exact right way to do it in this instance. That is what is good about c.
However you need to remember that C is designed for line editors, back in the old days when you had terminal and you had to select a line you wanted to edit, then it appeard in the line down the bottom, then you edit it, then it writes it back for you.. see vi for an example of this. Hence why C will let you do for (int i=0,j=0; i<100; j+=++i) { on a single line because back then editing multiple lines was a real pain. And has no relevance today and that is why any c programmer would not do such nonsense and any lead would bash with a stick if you did. Because yes you should do

Also if you want to get good c++17 code on a 6502 you can see https://www.youtube.com/watch?v=zBkNBP00wJE and you will see the C++ really evaporates when you use the const tricks and other tools to help the compiler optimise for you.

It seems your issue is more that you want to be a "good" programmer and thus your ability to see that i++ allows for an inc over an clc adc should make better code and damn that compiler for it ignores you and just makes either case the best case regardless of how "good" you are. And that is silly and a waste of your time, what you should focus on is coming up with the algorithm and means of achieving the task at hand that solves it in the fastest way possible and let the compiler work out if its better to do an inc or adc for that case on that line. i.e things like converting ptr = y*320 + x*8 +row in a loop into something like ptr += 165 to save all that extra calculation work each loop.

That is because the language has no GUI, or built in windowing system. Just like 6502 has no windowing system of gui or graphics system. If you want to learn a graphics system you need to look up tutorials for the one you choose. The WinAPI is for most parts the best, it is kind of why we all use windows. If you are talking the Win32 GDI(+), then Charles Petzold makes amazing books, they are tomes, well written, very easy to read and will give you solid coding methods and design methodologies to follow.
https://www.amazon.com/Programming-Wind ... bc?ie=UTF8 or the 6th edition if you can find it.
MFC don't touch with a barge poll. WPF go C# in Visual C# and forget the rest. XAML is a nice improvement and I find it much easier to get along with, however I feel its learning curve is higher than WPF. But both are in the drag-drop double click and edit and continue on the code for super sweet development experience.

Qt is ok, it has a lot of pain points, its clunky and will cause you to pull your hair out if you don't understand how to make "qmake" scripts and its custom build system and you need to be well versed in c++, qstring vs cstring vs bstr vs std::string for example. SDL is fairly straightforward, X is written in "cardboard" and is going to be archaic as, but there should be a tonne of tutorials in it if you can find them ( wayback machine might assist)

It sounds like what you really want is to run DOS BOX, read Abrash's Black Book and use 'MODE X' however DX7 would also probably suit your style if you could get it to run.

A language is only as good as its best free implementation. How much would it cost to hire a professional compiler developer to whip cc65 into shape, including "const tricks and other tools" that Oziphantom mentioned? And how do we get backers to cover this?

In light of this pointlessly mean comment, I just want say that I think rainwarrior is one of the most invaluable members of this community. From what I've observed, he doesn't come here to criticize or complain -- he comes here to learn new things and, crucially, to share what he's learned. What's more, he usually does so with admirable patience and goodwill. I've learned a ton reading his posts and his responses to others' posts.

Lizard is clearly a labor of love, as can be seen in literally every screenshot and video clip he shares. Four years is indeed a long time, but he's only one man, and evidence strongly suggests that he's working hard on it.

For the record: I love Rainwarrior and only wish the best for him. I watch his videos, I read his blog posts, and sometimes even his twitter. I love Bregalad too, but he doesn't share as much these days so I can't love him as much (Share more Bregalad!)

It was a pretty mean comment, yes. They might hate me for it, but it did stop their argument and let me vent about my lack of Lizard so I am content.

No it didn't. Bregalad just hasn't visited this site since his last post, so there hasn't been a reply.

qfwfq thanks for the words of encouragement, though I don't really want to use this thread to talk about Lizard (which isn't even about NES stuff at all). If you do want to talk about it elsewhere though I try to keep myself open for discussion.

Pubby, as far as your words here, maybe you think praise is an antidote to insult, but really they just devalue each other. You asked me not to take your words "too seriously", and that seems to have been accomplished? I don't understand why you'd want to accomplish that, though, which is actually why I asked.

The best way is to probably do what the guy in the video did and make a i386 to 6502 cross assembler and use the current compilers.

Going back to DementedPurple's original question, could it be that we're massively over-complicating the issue by even talking about the boot sequence and all that? It's kind of a long way of saying that if you're using a modern system-on-a-chip, that rules out bare-metal programming. You absolutely can buy a microcontroller and have it run only 100% your own hand-crafted code, but if you're assigned the Rasp Pi for a school project, you'll just have to work within that.

Maybe this is naive, but wouldn't it be possible to just make a program like this?



And then link your assembly code in? In your asm code, if you need to use the libraries associated with the hardware, then you'd learn how to call the C function from asm, as well as how to accept return values when needed. And I guess in your asm you would just declare those function names as extern, global, or something. You'd have to include them in an .H file I suppose. And it would all get sorted out at link time, right?

There's also the option of doing inline assembly, but so far whenever I've looked at that for GCC it just looks disgustingly ugly (if you're wanting to write more than a few lines for it). Having to put every line in quotes, and adding \n to the end of every line, ugh. It's almost more characters of compiler syntax than there is of assembly code. And if I understand correctly, with inline asm there's also the issue of the compiler dicking with your code. Like if you read the same memory or register twice in a row, the compiler would just optimize it to one read. Good luck polling a register like that. Of course the solution is to declare it "volatile", but I'm just pointing out that it's probably better to just make a separate .ASM file that gets linked in, if you're doing anything significant in assembly.

I don't know if that helps, but those are my simple thoughts on how you'd program a Raspberry Pi in assembly. Personally, I'd say learn the assembly if you want to, but C is useful and is used pretty much everywhere. When you're used to C, it's much faster to code something in it versus assembly, I doubt anyone would argue otherwise. It certainly worth learning. Seems like mostly people complain about having trouble understanding pointers, but if you know assembly and indirect addressing, you're doing to have no trouble understanding pointers.

That's possible; so is implementing main() entirely in assembly. You could write an entire C program without writing a single line of C code. Your main() function will be called by the C startup code, and you can call the C library functions. This avoids the complexity of trying to interface directly with the operating system (the C library does it for you) while still allowing you to write all of your code in assembly.

It's also possible to write a program in assembly without using the C startup code or the C runtime, but you'll have to do a lot of research into the kernel's ABI in order to make things happen, and you won't be able to call any external C libraries (since they require the C startup code to run before they can be called).


Only the functions that you intend to call from C. If you write everything in assembly including main(), then you don't need any .h files.


The ugly syntax is necessary because GCC doesn't parse the inline assembly at all beyond some string replacements for input and output values. It's certainly not intended to be used to write an entire program.


Every complaint I've seen along these lines ended up being traced back to some misunderstanding about what the compiler can and can't do with your inline assembly. It doesn't help that most examples of inline assembly are wrong, but worked for the author by some coincidence. (The Linux kernel is a good resource for examples of correct inline assembly.)

Which raises the question of how to bias the current compilers away from operations that are cheap on i386 but expensive on 6502, such as 32-bit arithmetic.

The problem here was more my own original misconception about the language when I first learned C. Some tricks make a piece of code looking shorter or more optimized, but it has nothing to do with actual optimisation, as you pointed out.


If you enjoy using the language, by all means this is fine. You should just understand it might be painful to other people. Other people don't have to use your favourite language (or even worse, your employer's favourite as it seem to be the case here), they should just make up their own opinion on the matter.


You are modifying what I tried to say. I said it looked like an optimisation, but wasn't a real optimisation. I didn't say this disallowed to optimize.



So you are doubling my point that C is lacking, because it cannot do those things, C++ (which is a different language) can but this is another story.


The point was just to say it's fine to program in something else than C or C++, that's all. I do not think there is any other language that is perfect. I just think that neither C nor C++ are perfect, not even close to it. That was my point. I don't need to have another language that is "perfect" to make such a point.


My point exactly.


In my personal opinion, I think a good language should never allow a subroutine to modify any of it's argument. Problem solved, arguments are passed by either value or reference, it doesn't make any difference. If you need the value to be changed, you should be required to do an explicit copy. This makes things clearer at high level thinking AND it allows for maximum optimisation of code generation.

The problem with C is that it will only inline or optimize routine if you add "static" keyword which actually means local. This was introduced only recently, and wasn't present in the original C language where they didn't allow any call optimisation, so originally C programs had to push all their calling arguments on the data stack in all cases.


Thanks man ! What do you want me to share more exactly ?! I don't really understand.


OH pardon me for continuing the argument. I see now that I ruined the chance to stop it. Anyway it was not really an argument, I was just claiming that it makes sense to want to avoid C for whathever reason, and it went a bit off track from here.

The entire point I am trying to argue is: when you enthusiastically agreed with when I said

maybe there's actually an interesting point to made that C is the "unhappy medium", too many abstractions over the hardware for...something... but simultaneously too few abstractions to make things easy.

But you blew right past the line right after:

But I'm about 99% certain that that position is indefensible.

My point is that anything bad you think is true of C is also true of machine code.

If the problem is mutability of arguments, that's one of the features of the const keyword. Using const as a convention for all arguments would accomplish your goal here. That's actually one of the things I like a lot about this language, you can turn mutability off like a light switch, on a per-use basis.

I was comparing Python, which makes immutability an inherent property of some types and not others. It succeeds at doing away with the distinction between "value" and "reference", but in comparison it's effectively all references, just some types are inherently "const". That example I gave of Bytes and ByteArray is one place where this gets really awkward, instead of being able to specify mutability on a type as one additional modifier, you have to use these two parallel implementations that are not equivalent or entirely compatible otherwise (Bytes and ByteArray are like the same goal designed by two different people who don't like each other). In general I don't think it's possible to make a mutable and immutable version of the same class except by re-implementing it.

Or Java, where except for a handful of special primitive types, everything is a reference, but at least you can encapsulate private members, and you can cleanly/easily make an immutable class variant with inheritance.

Functional languages like Haskell tend to have much more clean and consistent arguments; it's doing exactly what you're asking on a rigorous basis (all arguments immutable), but the "no side effects" mantra comes with a lot of other restrictions.

Is Haskell your idea of a "good" language, or could you maybe provide an example of a language that does it the way you want?

(I'm not trying to bait an opportunity to dump on whatever example you give, I just think defending against a complaint you have about C is not a very good way to see what it is you actually want a language to do; it would be much more interesting to me to know this than what you hate in C.)


Inline functions do not require the static keyword, it merely requires a local definition. It can be used inline locally and still called externally. Using "static" is only to disallow the possibility of external linking, which may be a common desire/convention when writing inline functions, but it's not a requirement.

This was not introduced recently, inline as an optimization goes back for decades. The explicit keyword hint "inline" was standardized in C99 but an extremely common extension for many years before that. (The optimization technique is valid and can/will be applied without the keyword hint.)

Something that was introduced relatively recently is "link time" or "whole program" optimization, which specifically can attempt inlining at the link stage, among other things. It does that very thing you wish it could!


I don't think anyone here was ever arguing that other languages aren't valid? I responded because you made a specific attack on C/C++.

I've never heard of the optimizer doing anything inside inline assembly code. ?? That's actually the point of using inline assembly: to get exactly the code you specified. Volatile applies to C, not inline assembly.

As far as the convention of putting \n in inline assembly, you can just use a real newline in the middle of the string literal, but I think a lot of programmers do not like the look/feel of multi-line strings. that's unfortunately due to the syntax using a string literal where there's no other way to get a newline.

edit: corrected my mistake.

Huh? Newlines are not allowed in string literals in C or C++ (discounting raw string literals added in C++11).

Yes, and it took 20 years of gcc development effort to get there. Thus my previous reference to "enormous amount of effort on the compiler's side".


I have never programmed anything in Haskell, so I cannot comment.

The problem with "const" is that you have to use a keyword to get behaviour that should be the default. The same with static functions in C. I'd rather have keywords for "extern" and "variable".

As for a language that is great, I think Pascal is great, I haven't used it much but it seems ADA is great too, and Python looks pretty damn good too despite some inconsistencies here and there. LISP seems interesting but I have yet to use it for anything. But I'd never limit "great" languages to those. I fully agree that I'm in a "the grass is greener elsewhere" where I think languages I didn't use much are better than those I used a lot (and I think so because I've been told so). On 6502.org forums they're fond of the forth language and they all told it was the best language ever, all my attempt at approaching this thing ended with complete failure and to be honnest programming in Forth sounds even worse than programming in machine code, and I fail to see why anyone would want to do that.

Oops, yes you're right. I was probably thinking of a different language. Anyway, that problem is the cause of the ugly "\n" in inline assembly syntax that uses strings.

I always just lived with that convention (esp. cause inline assembly was rare, and longer stuff could just be done with a separate assembly only file), though I think I usually would use whitespace to put all the \n over together in a column away from the code. Not great for editing but at least keeps it from sticking to the assembly code.

MSVC didn't try to do it with strings, and it looked a lot cleaner, by the way:
https://msdn.microsoft.com/en-us/library/45yd4tzz.aspx

Either force the programmer to use 16bit maths for int and use long for 32bit maths and then downgrade in the conversion or use gcc and -m16 flag to put it into 16bit compatible mode. Also I said best not good

I wonder how good say the last version of the Borland 8086 compiler was.

100% you can do this, however I feel that Demanded Purple is more looking to hit the PI like a NES and just write something to a register or RAM to get something on the screen so they don't have to deal with complicated APIs to draw things on the screen and the like, rather than actually write in ASM over C.

I disagree. As sometimes I want to return multiple things from a function call, say bool myFunc(int param1, int* result) this allows me to get a result AND know if it succeed without having a magic unsafe value like INT_MIN. And no throwing an Exception is not a good way to solve the problem its bad and annoying one
Passing a short is faster by value than by reference. If I want to pass in a 64K array then by reference is best, copying 64K is a drain on performance.
It is worth noting at this point C doesn't have by reference that is a c++ thing

This does give me more control as now I can pass

To create the exact level of code protection I need. Ignoring the fact you can just cast const away
These are for protection and forcing an API not an optimisation. Given int myFunc(int i) { return i+5; } while I do not mark i as const, the compiler will work out it is const and optimise for it automatically, I can put the const word there to stop me or somebody else in future modifying i but that won't change how the function is compiled.
Likewise the inlining of functions is 100% up to the compiler and the compiler will inline as it sees fit, the myfunc above on a release build with -02 or higher would most certainly be inlined as just an add op-code in the parent code without me putting inline on the prototype. There is a case on gcc that you can basically force it to inline if you have static and inline in the name but this is more a quirk rather than a standard, the static is there to ensure the linker doesn't make multiple instances of it and hence all of them get folded into the same case. Seeing as C doesn't have classes everything is Static by definition.

In assembly, I do this all the time, and it's a trivial thing to do. I just use the A register for the result and the C flag indicates wether a correct result is returned. Couldn't be any simpler.

In C you have to ressort to a "hack" of passing a poitner to a function which is not a real argument, but a return value. This seriously hinder code readability. In addition this removes possibilities of optimisation. WHY, oh good lord why ? You just showed how terrible C is. If I could just return an "int, bool" pair, that'd be much better ! But C can only do that with structs, which are their own complicated thing in their own right.

You just summarized how broken C is in a few lines. This garbage basically don't even look like code.

To clarify what I meant, when I said "pass by reference", I was referring only to the difference between passing "by reference" or "by value". If you pass a pointer to a function and use that pointer to reference an object, this is still the "pass by reference" idiom. I wasn't referring to the C++ & argument modifier (usually equivalent to the pointer but with its "value" part hidden).

You could insist that C only has "pass by value" by some definitions, but I'm just trying to clarify the meaning of my words in this thread.

What optimisation has been removed? Its not assembly there is not a 1:1 relationship between what you type and what is spat out. There is nothing to stop the C compiler from returning the Bool in C and *result in A. There is also nothing stopping it from inline the code such that it never returns anything and the Bool gets turned into a Jump or branch further down the code and the *result is just generated in A, an optimisation you will never get with a function in ASM. Maybe it decideds it is called so much that it puts a static variable to hold the value on the heap and thus just writes the value to that variable and all code there after loads from variable to save it from having to push and pop it on the stack multiple times, if your code needs to save and refer to the returned value a lot in the code that follows your calls. Just because something is in the function params or a return from a function doesn't mean it has to be called or passed that way, the ABI can define a standard way, but the optimiser will do it any darn way it wants, as it seems to be most optimal for all cases it is used. However if you really want to nudge __fast_call will use Pascal passing as default over a default C, but I doubt compilers even listen to it any more either, but maybe they do in a debug build.

Also which of these is more readable
or

much of a muchness? lets try a larger example

or

the C case ( and in the 2nd case use a struct ) has named things for each param the earlier case has magic numbers that index into something to pull something out. The named version is going to be a lot easier to read and maintain. Also in the C case the compiler can put 2 dummies on the stack, then push the rect_x,rect_y,rect_width,_rect_height, thus when it wants to call collide_point it just overwrites the dummies with point_x and point_y and optimises the push and pull away. as poping 4 or 6 things off the stack takes the same amount of time. Which it can't do in the multiple return case as you have fixed index looks up in the array, I mean it can modify the index to switch over if it has put each item on the stack and not put an object on the stack that is a real list or something...

Why is being able to strictly control what a function can and can't do to a variable broken. It alows you to make the definition exact and binding, it allows you to get the compiler to catch bugs for you, the static analyser to help find issues, it allows you to make code thread safe. Its when you get to a language that has seemingly random rules on what does change something passed in and what won't change. See Python, String can't change, List can change , Tuple can't change, dictionary can change, Byte array can't change, byteArray can change. In C it is explicit and written in the prototype for all to see and if you try to break it, the compiler will stop you. Not give you a random crash when person clicks button C then D, then A then F.

Python has tuple unpacking, so you can do:

C++17 allows something similar through "structured bindings".

It becomes unwieldy with more than a few return values though. At that point it's better to starting using structs. (The C++17 structured bindings allow one to unpack structs as well, which is pretty nice.)

Passing a pointer to a function removes possibilities for optimization. The caller doesn't know what the callee will do with the pointer, so the variable has to be in RAM (it cannot be in a register), so that pointing to it is possible. It has to either push the RAM address on the stack or putting it in a register, before calling the function.

The calee has to use this argument and write to this address. The compiler doesn't know what the adress is and doesn't know it's a variable in another piece of code. The explicit pointer kills the opportunity of an optimization. It's better to let language manage memory their own way and optimize it rather than requiring the user to manually managing memory.

In practice, yes with modern copiler they could do a lot of optimizing effort and see under some conditions that it's possible to optimize this out. I didn't veryfy since then, but I'm pretty sure GCC 4 could *not* optimize this, and passed the pointer to the calee, even if doing so was avoidable.

The optimizer can't change the inline assembly code, but it can change where and when said code is used. GCC assumes by default that any block of inline assembly will produce the same output given a specific set of inputs, with no side effects. If that's not true, you need the volatile keyword. (Inline assembly with no outputs is always volatile on the assumption that it must have a side effect; inline assembly with no outputs and no side effects would do nothing and be removed by the optimizer.)


Sure, but you trade some potential optimizations for that cleaner syntax. GCC's horrible syntax allows you to directly inform GCC about how it may optimize your code, in a way that doesn't require GCC to parse assembly for every CPU it supports.

Using a pointer instead of a value is a potential optimization by itself, i.e. reduces the call preamble (less arguments to push to the stack). This may be a tradeoff against how much that pointer is dereferenced inside the function. Putting a structure in registers or the stack is not necessarily faster or slower, it could be either.

Your suggestion that being able to specify which of these two behaviours you want somehow removes an optimization opportunity... I don't understand at all. If it can be inlined/etc. the pointer dereferences can be inlined and optimized away, but otherwise there would need to be some mechanism for the compiler/language to identify which way of passing arguments is overall faster. (This is not necessarily a decidable question; e.g. you could have dereferencing of the pointer inside a loop with length dependent on an argument, which could not be determined statically.)

So the question here again is, what language are you comparing against? Of the languages I know that don't have this kind of distinction, none of them have any special capability to optimize subroutine calls in this way, to my knowledge.

C letting you specify means that you can make this determination yourself where static analysis is impossible. "I know this loop is going to be run 500-700x per call, usually." It makes manual optimization possible where static optimization was not. A gain, not a loss?


Ah, so the volatile keyword has a special meaning when applied as a qualifier to the asm block. I understand now, thanks. I thought memblers was suggesting using it within the inline assembly somehow.


You're referring to MSVC's __asm not having a way to specify inputs/outputs/clobber, and letting the assembler deduce it instead from the code inside? (This has not much to do with the problem of using string literals that started this discussion... heh...)

Honestly I'm not sure which of these methods is better in practice, though. asm being more error prone and ugly, and __asm being less customizable? You're already optimizing "by hand" in either case, so whatever missed opportunity for optimizing code around the block I guess could be addressed by expanding the scope of it a little...

In the last several years though, I've seen a lot less inline assembly and a lot more intrinsics/builtins which I think are usually a better fit for the kind of problems where I used to go for inline assembly.

Just wanna give my two cents on all this.

OP, besides 6502 assembly, what other languages do you know? I'm just curious because your opinions on higher level languages and not wanting to use libraries remind me of myself when I first got into nesdev. If you're up to the challenge, go for it, although i think you may be in a bit over your head. Assembly is fun, but I'm honestly pretty happy we don't have to use it that much in modern day computing. It still is kinda sad that it seems to be becoming a lost art in a sense.

As for this however-many-page debate going on: I honestly feel like C is the best balance between assembly and the huge abstraction of other high level languages that there is. As Bregalad pointed out (unbeknownst to me) the compiler still does a lot that the programmer doesn't know about, but in my opinion at least (and to an extent of course) I don't really care about micro-optimizations when I'm coding in anything other than assembly, unless its something trivial.

C++ was the first "real" language I learned, but after learning C, there are a lot of things I don't like about it. Scope resolution syntax lile "std::" looks ugly as hell in my opinion. Templates are about the furthest I've delved into the language (or plan to.); everything past that just seems like unnecessary bloat / kludges. Are any of these other "aspects" of C++ used that often?

It seems interesting to not care about micro optimizations, and yet still care about perceived bloat. I don't mess with too many modern C++ features yet, but I don't mind them being there.

I like new over malloc, fstreams over fopen, functions in my "structs", constructors/destructors. I had actually written my own code for vectors, not realizing they already existed. Vectors are also pretty sweet.

I'm not sure I can express how much destructors (and vectors) do for allowing one to think less about memory allocation.

I don't like cout over printf, but in C++ I can use printf and in C I can't use new. So I use C++ over C, primarily for small things. I used to not get the "object oriented" methodology, until I realized that the "best practices" rules of thumb I picked up while coding in assembly language were very related. (Not sure... I can put how into words well.)

I still write c on occasion, just for the fun of tiny c compiler, but I don't have much reason to not use C++ even if there was nothing I liked about it over C except new. C++ does seem to offer a lot of crazy things lately, but you can pretty much always avoid them and write pretty c-like c++.

Or someone worries about not enough space in an NROM-128 project for the credit required by the license.


Or someone doesn't care about micro-optimizations for speed but does care about them for size in an NROM-128 project.


I tried fstreams over fopen using GNU libstdc++ several years ago. A single, simple use of ostringstream gave me a 180K Hello World binary on a Game Boy Advance, which has only 288K of RAM (256K of bulk RAM and 32K of fast RAM) for RAM-based programs. I looked into it, and the linker was failing to remove unreachable code related to date, time, and money formatting. This forces practical C++ programs that use iostream on that platform to be ROM-based, which makes use by players 2 through 4 in a multiplayer match more expensive. (GBA supports multiplayer with one cartridge so long as the program running on the machines of players 2 through 4 is RAM-based.) In addition, low-end memory card adapters such as the GBA Movie Player can run only RAM-based programs.

This library is pretty sweet: https://github.com/fmtlib/fmt

Sure, but the more you write in assembly the less the compiler can optimize for you, and you might want to be able to change the optimization profile for different CPUs.

Either way, it's a tradeoff: MSVC's __asm is easier to write and debug, GCC's asm() is better integrated with the optimizer.


They're the best of both worlds: easy to read/write, and fully integrated with the compiler.

That's not perceived bloat just from reading documentation, which is what the person I was responding to seemed to say. I feel like a hypothetical NROM-128 project is outside that context. But I still disagree with the premise. If you're making an NROM-128 project you could still get more mileage for size out of assembly than the "bloated" by comparison C, right? "But someone could care less about the size benefit of assembly and care more about the time it takes to write in an NROM-256 project." Yes. Sure. Okay.

I guess in general, I feel that while the information presented may add to the thread, I feel that because it's posted as a reply to me, but not as a reply to what I feel like I said that confuses me about how to respond. I answered about features from C++ I use that aren't templates, it doesn't mean there's never a reason not to use them. I can see how that can maybe be gotten from "I don't have a reason to use Y", but I'd have said "There's no reason to use Y" if I meant that.

Heheh! I know of it. It might be interesting to start a C/++ resource thread, but there's not much I can personally cosign as "used in an actual project".

I mean the whole point of high level languages is to abstract away from the underlying asm, so when I'm coding in C I'm only worried about optimizing on a macro scale. Unless I was doing something time-critical/embedded, the amount of time/effort it would take to either A.) write inline-asm that doesn't break the rest of the program (and doesn't gcc force you to use the ugly AT&T syntax for x86?) or B.) writing C code that translates into optimal asm isnt worth it, to me at least.