Is this an alternative to C?

[elmer]

The big problem that I'm seeing with both HuC and CC65 is that they're both really, really dumb.

They seem to often generate lots of code that they don't need to.

Now, maybe SDCC will be smarter ... but that's still to be determined.

The question in my head keeps on coming back to "if the code that's produced is going to be so bloated and bad that I've got to rewrite it in assembly language, then why not just write it in assembly language from the start?".

Well, at least for me, one of the annoyances of normal assembly is just how much the minutiae of the language actually obscures what I'm trying to do.

As Arkhan pointed out ... it's hard to experiment with stuff when you're dealing with all that "clutter".

A good Macro Assembler with a large and well-designed set of macros can really help out there, but it's still not as friendly as I'd like.

I've just found NESHLA ... that takes an interesting approach to wrapping the annoyances of normal assembly language into something that superficially looks a lot more like C, but with none of the overhead of that stack-based language.

I've done a search, but nobody seems to have discussed this language here, what do folks think?

Does any else but me like the idea of something like this as a front-end that would generate code for PCEAS or CA65?

http://neshla.sourceforge.net/

[Arkhan]

That could be neat, but only if it really does an optimal job, otherwise, you can just do the C-->ASM by Hand thing.

As it turns out, much of the game logic for a game is pretty stupid easy, once you know what it SHOULD do.

So, the conversion isn't very painful.

[elmer]

That could be neat, but only if it really does an optimal job, otherwise, you can just do the C-->ASM by Hand thing.

I've taken a look at the source, and NESHLA takes the (IMHO) dumb move of actually being a full assembler and producing its own binary NES ROM files. That makes it unsuitable right now for the PCE.

But the concept of what he's doing there doesn't really need that.

The idea of that C-like structured assembler could just as easily be done as a pre-processor that spits out PCEAS or CA65 source files.

A pre-processor like that is easy to write these days.

All that it really is is just a way of writing assembly language code that looks more C-like, makes the code more readable by not obscuring the structure, and stops the programmer from having to manually deal with all those local labels and junk that makes assembly language more tedious than it needs to be.

What he's actually doing in NESHLA maps exactly to assembly language ... there is no overhead at all.

That's what I'm liking about it (as an idea). It's minimal.

I'm feeling that by the time that you've massaged your C code to use all static variables and to avoid generating all the "expensive" code, then you're basically back to simple instructions anyway, so why live with C's overhead?

BTW ... the cost/benefits of the NESHLA structured-assembler concept may change if SDCC eventually produces code that doesn't suck. At least it's going to be using a small-and-fast stack for any stack-based local variables/calculations.

[Bonknuts]

so why live with C's overhead?

This is the problem I have with HuC. I haven't messed with CC65, so m not sure about that, but it's not really the output code as it is the structure overlaying on top of it. The code can be optimized with replacement assembly stuff, but the structure is a pain in the ass (some stuff is impossible to do with HuC; no amount of assembly will fix it).

 I've seen NESHLA, and to be honest it always pops into my head when these C discussions come up. I like the idea very much, but there's one catch - if you need to have a strong grasp of assembly for the processor, as well as the surrounding hardware. So something like NESHLA is for assembly programs, not beginners or strictly C enthusiasts.

 For me personally, the only real nuisance of Assembly, is the wading through the listing. Everything's really long and so it's more difficult to quickly parse through stuffs. Having multiple files helps cut it down, but I always forget which file contains what.. so looking through them is annoying too. Writing code, designing logic and structure - none of that is a problem for me in assembly.

 I would definitely use PCEHLA. 

[elmer]

so why live with C's overhead?

This is the problem I have with HuC. I haven't messed with CC65, so m not sure about that, but it's not really the output code as it is the structure overlaying on top of it. The code can be optimized with replacement assembly stuff, but the structure is a pain in the ass (some stuff is impossible to do with HuC; no amount of assembly will fix it).

By "structure", do you mean all that messing about with putting expressions/temporary results on the C stack?

CC65 isn't really much different to HuC, it's just been optimized a lot more ... but then goes and throws away a bunch of that optimization by calling subroutines for some stuff instead of expanding the code in macros.

Either way ... both of them use "[sp],y" and "inc/dec sp" all the time which kills whatever is left of your performance.

They both do all the stack-based temporary math as 16-bit, but CC65 implments a lot of peephole optimizations that can sometimes make it somewhat less expensive than HuC.

But, it's just (IMHO) dumb to keep doings things as 16-bit when you don't actually need to.

*************

SDCC's code generator is completely different, which is why it stands a chance of delivering better code.

It internally figures out all the local variables, calculations and math in terms of temporary results (8-bit/16-bit/32-bit signed/unsigned), and then does lots of trial passes through the code-generator to decide which of these temporary results should actually be in registers or real locations in memory (either as static locations, or on the stack).

Since a small-stack access can be "abs,x", that's just as fast as a static "abs" reference on the PCE.

That's not too conceptually different to how an assembly-language programmer thinks.

I just don't know, yet, how well it's all going to work out in practice because I'm entirely dependent upon the SDCC "guru" to get the code-generator written.

The SDCC codebase itself is barely documented, and seems to rely on a lot of insider knowledge of state information that I just don't understand. 

So something like NESHLA is for assembly programs, not beginners or strictly C enthusiasts.

Yes, definitely.

There's not much that can be done for people that will only use C, but back in my day, assembly language was for beginners, or at-least almost-beginners. 

For me personally, the only real nuisance of Assembly, is the wading through the listing. Everything's really long and so it's more difficult to quickly parse through stuffs.

Yes, that's where NESHLA's approach really appeals to me (right now).

Assembly language isn't really that hard, but traditional assembly code can be a bit of a PITA to follow because of the verbosity and with the actual structure being hidden inside lines of code that look identical to the eye.

It's like running C code through an obfuscator that removes all the spacing and line breaks and just puts everything on the same line.

Perfectly legal C code ... just a huge PITA to read and understand.

Writing code, designing logic and structure - none of that is a problem for me in assembly.

Yep, assembly coding itself usually isn't that difficult. 

[Gredler]

Yep, assembly coding itself usually isn't that difficult. 

 

[elmer]

Hahaha ... no, really, I mean it! 

Don't forget, teenagers at school were doing it 30 years ago.  :-"

[dshadoff]

Hahaha ... no, really, I mean it! 

Don't forget, teenagers at school were doing it 30 years ago.  :-"

It's true.  I did.  But it's not like there were hundreds of languages available for home computers until 5-10 years later.  Some of the languages which were available were of questionable use (look up 'logo' and 'Forth').

Z80 assembler was the second computer language I learned (BASIC was first).
6809 assembler was the next one.
And I was about to learn 6502 as my next language (but the 6502 was dying by that time).

...But this was one of the problems of assembler - one had to conform to the system one was writing on.
After the plentiful registers on the Z80, it took a lot of effort to wrap my head around the minimalist 6809.

...we were patient back then.  I recall saving my programs on 500-baud cassette tapes for 26 minutes per copy.  (Of course, I made backups too).


Oh, and can you guess why anybody would learn assembler ?
Because it was about 100 times faster than BASIC.

[elmer]

Some of the languages which were available were of questionable use (look up 'logo' and 'Forth').

Amazingly, the vestiges of FORTH still exist. What a beautifully horrible language.

A masterpiece for it's time, and an absolute nightmare.

I considered making AtLast (AutoDesk's interesting 32-bit derivative of FORTH) the in-game scripting language for our company's game engine.  :oops:

After it because clear that every other programmer would quit, I relented and we implemented something usable instead. 

Z80 assembler was the second computer language I learned (BASIC was first).

Me, too. What machine did you get to start on? I think that you're an American, so perhaps an Altair or TRS-80 or something like that? 

My school got a RML-380Z with a 300 baud cassette, and I was one of the early users of that.

https://en.wikipedia.org/wiki/Research_Machines_380Z

Same path ... BASIC, then assembly ... mostly so that I could do incredibly "mature" things like hacking the BASIC interpreter, which loaded from cassette, to say "TAMPAX ERROR" instead of "SYNTAX ERROR".

Some of us were were nerds, even back before the term was coined.

After the school finally bought a dual 8-inch floppy drive, there was no stopping me!

6809 assembler was the next one.
And I was about to learn 6502 as my next language (but the 6502 was dying by that time).

I'm jealous ... I've always wanted to have a chance/reason to play with a 6809!

I went straight from the Z80 to the 6502 (on the Apple II).

...But this was one of the problems of assembler - one had to conform to the system one was writing on.
After the plentiful registers on the Z80, it took a lot of effort to wrap my head around the minimalist 6809.

And this is really the issue. Early microprocessor architectures were very different, and they weren't designed with high-level languages in mind.

This is why C is such a lousy fit on the PCE.

It wasn't until the late 1970s that the M68000, Z8000 and NS32000 came out (that were all based upon ideas from expensive minicomputers), that microprocessor CPUs were really designed to run high-level languages.

You can just about throw Intel's 8086/8088 in there, too ... but it was mainly designed for backwards-compatibility (at a source-code level), rather than forward thinking.

Unfortunately, IBM/Intel won the marketing battle, and we've all spent decades locked into that horrible architecture until AMD finally came up with the x64 improvements, and Apple made the ARM chip sexy.

P.S. No, I'm not forgetting MIPS, SPARC or PowerPC ... they just had a very limited niche.

[spenoza]

P.S. No, I'm not forgetting MIPS, SPARC or PowerPC ... they just had a very limited niche.

PowerPC was more widely used than many suspect, though in some weird places.

[elmer]

PowerPC was more widely used than many suspect, though in some weird places.

Yep, good point. It would count as more successful than the Z8000 and NS32000 combined ... and that's just in the GameCube! 

Being a game guy, I can think of Apple PowerPCs, GameCube, Wii, WiiU, Xbox 360 and PS3 ... and I'm sure that it must have had a different and successful life in the embedded world, too.

Didn't it also get used in some of IBM's server and supercompters somewhere?

Can you think of other examples to help me out?

[Bonknuts]

I did BASIC as a kid, and learned C with OOP (that's what it was called in 1993/4) for about 6 months as a late teen. In 1999, I learned x86 assembly and z80 assembly at the same time. That was about 6 months, then directly switched over to GBz80 assembly (Gameboy) for another 6 months. And then stopped.

 It wasn't until 2005 that I started huc6280 assembly. About a year later I started learning C again (this time without OOP nonsense) so I could write support utils on the PC. The rest is history (with other processors thrown in). So it wasn't until 2005, when I was 29, that I really delved into assembly. I loved it.

 65x was weird to get used to at first, but I never did like x86. It felt soo convoluted in approach (I did page mode addressing) - even without having any other experience with other processors. Looking back now, after coding more modern processor designs, I was right. Going back to z80 after all these years, I don't like that it doesn't have direct memory load/store into the A register (everything is pretty much done through the A reg like on the 65x and 68x and other related processors, so this bottleneck sucks). Too much register juggling - and stack use. The nice but limited 16bit macros (hardware macros) don't make up for it.

 Off topic: I read that AMD was going to release a new PC processor with an ARM core. I thought this was a fantastic idea; much better ISA - and get away from the x86 design. But I haven't seen anything about it in more than a year. I thought that would be the next big thing like x64, but I guess it silently felt through the cracks.

 Edit:
Pic 16f84 and related series MCU are the worst processor that I've ever coded assembly on. That processor is insanely crippled. About the only thing worse would be trying to program a DSP chip as a regular processor (it's almost the same level of convoluted-ness).

[spenoza]

PowerPC was more widely used than many suspect, though in some weird places.

Yep, good point. It would count as more successful than the Z8000 and NS32000 combined ... and that's just in the GameCube! 

Being a game guy, I can think of Apple PowerPCs, GameCube, Wii, WiiU, Xbox 360 and PS3 ... and I'm sure that it must have had a different and successful life in the embedded world, too.

Didn't it also get used in some of IBM's server and supercompters somewhere?

Can you think of other examples to help me out?

IBM used it for a while in the Power series servers, and the 603 and variants were used as embedded controllers for lots of stuff. Various 603 versions powered Sega's impressive Model 3 arcade boards (precursor to Naomi/Dreamcast) and Konami used a bunch of PowerPC variants in arcade machines as well. You can bet Motorola was doing their best to sell that chip to anyone who would buy, because Apple wasn't necessarily perceived as a safe business partner at the time.

[spenoza]

Off topic: I read that AMD was going to release a new PC processor with an ARM core. I thought this was a fantastic idea; much better ISA - and get away from the x86 design. But I haven't seen anything about it in more than a year. I thought that would be the next big thing like x64, but I guess it silently felt through the cracks.

They are developing it for low-power, low-cost blade servers. It's called the Opteron A. No idea if it is a successful platform.

http://www.amd.com/en-us/products/server/opteron-a-series

[TheOldMan]

I did BASIC as a kid, and learned C

in order, as I remember it....
Pascal. Fortran 4 then 77.Cobol.  PL/1. 360/370 assembler. Logo. Basic. C. 6809 assembler. 386 assembler
Then, in no particular order...
C++ / Java /C# /MIPS assembler / and finally, 6502 assembler.

Most of the early stuff was in college. 2 years of fortran, right around the change over from 4 to 77.
I also learned a smattering (enough to do the ssignments) of Lisp and prolog, but not really enough to do anything serious with.

Logo/Basic/C/6809 were from my CoCo days, near graduation. That's when I fell in love with C - and learned to speed it up with assembler Somewhere around here I still have a kABOOM! clone for the CoCo. Analog sticks were awesome .

The rest were things I picked up helping my nephew and others do their school work. C++ was nice, if inefficient. Java was worse. 386 assembler was...meh. Mips assembler was courtesy of the ps1/2 and an introduction to linux. (Remember when it would boot from a single 1.4M floppy?)
And now, the pce and 6502 based assembler.

And my best programming memory of those times...Setting up a network (wow 10Mbps) in house, and being challenged to write battleship. Over the network. My nephews friend used visual c, I used Borland C. He turned it in as a school project ("Write a simple game"), showing how to do networking in both languages...and almost got expelled because everyone in school was playing and dragging down the network.

Good times.