nesdev.org

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

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?

pubby wrote: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

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.

pubby wrote:it did stop their argument

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.

Memblers wrote:Maybe this is naive, but wouldn't it be possible to just make a program like this? [...] And then link your assembly code in?

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).

Memblers wrote:You'd have to include them in an .H file I suppose.

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.

Memblers wrote: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.

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.

Memblers wrote:And if I understand correctly, with inline asm there's also the issue of the compiler dicking with your code.

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.)

Oziphantom wrote: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.

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.

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

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.

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.

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.

(I can't optimize because I can't specify when to use the zero flag with ! vs ==0)

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.

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.

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

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.

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).

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.

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.

My point exactly.

In a lot of other high level languages you don't even have options about whether something is passed by value or reference.

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.

I love Bregalad too, but he doesn't share as much these days so I can't love him as much (Share more Bregalad!)

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

rainwarrior wrote:

pubby wrote:it did stop their argument

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

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.

Bregalad wrote:So you are doubling my point that C is lacking, because it cannot do those things, C++ (which is a different language) can

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.

Bregalad wrote:

In a lot of other high level languages you don't even have options about whether something is passed by value or reference.

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.

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.)

Bregalad wrote: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.

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!

Bregalad wrote:

rainwarrior wrote: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).

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.

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++.

Memblers wrote: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'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.

rainwarrior wrote: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.

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

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!

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".

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 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.

thefox wrote:

rainwarrior wrote: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.

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

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