|
11917640 Member wrote: Multiplatform Assembly Programming - such thing doesn't exist.
I'd disagree. There are a lot of aspects of assembler language programming that are largely independent of the target architecture.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I hate to be difficult, but it seems like C (or - fight me - even C++) is a better fit for this.
I mean, sure there are some instances, like doing SIMD where dropping to assembly might be a win, but that's going to be platform specific code, otherwise there's no point.
Seems to me that dropping to assembly within one of those, while generating most of the bytecode you otherwise need using C is far more "cross-platformable"
I didn't read the book, so is there a reason the approach I just outlined is insufficient?
To err is human. Fortune favors the monsters.
|
|
|
|
|
You are an embedded person (nearly said guy!) the only times I have used assembly is when I needed real speed reading a port.
|
|
|
|
|
I've been an embedded engineer for my whole career and the only time I dropped into assembly language in the last 20 years has been to use a specific assembly language instruction in the TI DSP I was writing code for. It was a 'saturate' instruction. It took a 40bit accumulator value and limited it to a 16bit value. Other than that it's been C/C++ for me for at least 2 decades.
|
|
|
|
|
I fear you misunderstood my point. I was merely suggesting that there are aspects of assembler programming that are largely independent of the target platform/instruction set.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I think I understand your point, it's just that it still seems more suitable to me to use C or C++, only dropping to asm for platform specific things. Despite assembly being somewhat similar across different platforms, sometimes, there are enough differences that it can get hairy fast. C does a lot of the heavy lifting in terms of papering over different machine word sizes, alignment issues, and other things that assembly just doesn't.
So while you're not wrong, it still seems better to me to use something like C, and then drop to asm within that if absolutely necessary.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Please do not compare C/C++ to assembly language. One ALWAYS sits on the back of the other -- that is the only comparison. I am sitting here wondering how and when it became acceptable to program hardware with ANY compiled language!! 
I know all of the assembly languages in the books. ALL have enough similarities with one another that it is quite possible to learn them all. My main point is that you cannot compare assembly language to a compiled language for several glaring reasons -- no matter how hard you try. This isn't about who shouts the loudest (not saying you were shouting  ).
modified 26-Oct-22 21:01pm.
|
|
|
|
|
Far from comparing them, I'm contrasting them. C and C++ can do multiplatform code in a way that ASM cannot.
Bert Novilla wrote: I am sitting here wondering how and when it became acceptable to program hardware with ANY compiled language!!
If you're not joking, I cannot take you seriously from a professional perspective. Sorry.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I don't get the whole multi-platform comparison at all. Granted, I understand the way things are done commercially -- I have been there, too. But... today's programmers actually believe a compiler can be optimized to write better (or as good as) code than the average ASM programmer. Of course, no one ever proves it. The better way to "do software" is to hire dedicated teams for EACH platform, with the best assembly programmer running the show. When that happens you do each of the platforms a real solid -- and NOT make one slow, bloated "tool" that takes forever to compile and fits all platforms poorly.
I think I actually object to the phrase "dropping down to asm" because I see it as exactly the opposite. A couple of decades ago we wouldn't be having this conversation (with me in the minority LOL).
Again, HOW is it considered "standard practice" to program the slowest link in the data chain with a compiled language?
modified 26-Oct-22 21:01pm.
|
|
|
|
|
Here's what I haven't been able to get someone with your position to do for me:
Generate a string of optimized, non-SIMD instructions that I can't produce vicariously with C or C++
If you can do that I will reconsider my position.
The reason we wouldn't have been having this conversation 20 years ago is C and C++ compilers were garbage.
They are worlds apart than what we work with today. I used to lean toward your position. When compilers changed, so did I.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Be specific. What are "strings of non-SIMD instructions not produced vicariously with C or C++", and why not just ask the question you really want the answer to? I can probably tell you, and it will be the truth. I also have no idea what optimized means, other than I routinely re-work all code until it can't be beaten by any compiler -- size or speed. Heck, it's usually written that way the first time!!! To me, SSE (or MMX... another type of SIMD) is simply part of the package I use every day, and not some mysterious, far-off concept that "maybe" the compiler has intrinsic macros for.
We can leave it here, agree we each have our good points (I believe we do), or you can explain your question better and I will accept and win your challenge, whatever it is. I just know the difference between ASM and all compiled languages, and the compiler I use to create is a gift from God, the same one we all have and decide whether or not to make good use of. You're not beating that with a man-made anything.
One might even write a "Photoshop" in 1 MB using pure assembly! And it would take forever.  But, a team...
modified 26-Oct-22 21:01pm.
|
|
|
|
|
The following code bit bangs an 8-bit parallel bus using C++. It does so in a way that is extremely timing sensitive. It is something you would probably code in asm. Currently it only works on the ESP32 because I haven't coded for the hardware registers to flip GPIO on and off for platforms other than that - the timing is so sensitive that the generic API just isn't fast enough.
My point is though, this has to generate very specific bytecode for it to be fast enough to work. I had to run it through godbolt.org
It does. If you're not very familiar with C++ it won't look like it, with "if" statements all over the place and what not.
They are compiled out.
htcw_tft_io/tft_parallel8.hpp at master · codewitch-honey-crisis/htcw_tft_io · GitHub[^]
To err is human. Fortune favors the monsters.
|
|
|
|
|
I read your most recent comment in my email but it's flagged as spam for some reason here on the forum so I'll respond here instead if you don't mind.
You asked me what optimized means. That's fair. Let me see if I can clarify. Since it's situational, we'd have to take it on a case by case basis. Consider that if you produce a string of assembly, and my compiler produces a similar but different string, if it's not different but for some instructions that make it faster in at least half the situations we can think of I'll concede. Does that make sense?
The reason I excluded SIMD is because in practice it's the one area where I tend to "drop to" asm pretty frequently, because currently the compiler has narrow cases where it can find opportunities to produce SIMD regardless of how I structure my code. It's a good reason to context switch to asm from within C or C++. Those reasons exist and I'm not arguing otherwise. But I hope that clarifies why I added that qualification.
The code I posted in my second reply might clarify my position some.
To err is human. Fortune favors the monsters.
|
|
|
|
|
LOL! Yes, now what did I say that was so bad? Maybe defending assembly language? 
Oh, I don't even know what to say, or if it is allowed. LOL So, I would like to button my position with this: A man-made compiler can't beat the one in my head. Or yours. And it never will.
modified 26-Oct-22 21:01pm.
|
|
|
|
|
Where we don't see eye to eye, regarding our respective positions is your notion that hardware should not be coded on in stuff other than assembly. Now maybe I misunderstood your position but that was my takeaway from your initial reply to me.
I routinely interface directly with the hardware, in C++, on IoT devices where every byte of RAM and every CPU cycle counts, because I'm dealing with timing sensitive hardware, a real-time system, and very limited RAM and CPU.
The only reason I can do it is because I learned to code in assembly.
30+ years later I find assembly hamstrings me when I have to use it. All of the sudden, my code instead of working on the entire ESP32 line will only work on the Tensilica Xtensa 6 without nearly doubling the amount of code I have to write to get it to also support the Risc-V variant of the ESP32.
So I avoid it, even for development where I'm interfacing directly with hardware. And I can do so where every cycle counts.
I've written an NES emulator that runs in 240mhz with 512kB of RAM. Mostly in C++
To err is human. Fortune favors the monsters.
|
|
|
|
|
Different meaning, discovered with the high-effort act of reading the description:
"Covering the Z80, 6502, 68000, 8086 and early ARM CPUs"
|
|
|
|
|
Well I have a back ground in Assembly with the 6502, 8086, 68K and some ARM (which is similar to 6502...) I found it useful that they recomend emmulators that are 'freely' available and gave a full list of commands... read like a Learn assembly book from the 80's took me back
|
|
|
|
|
Should have said if you are assembly vetran and just need a guide to how code works rather than how use the chip.
|
|
|
|
|
I have no idea what she's talking about... I've lived here for more than 200 years and never noticed anything strange.
|
|
|
|
|
Brilliant.
PS: sorry I behaved like a bit of a jerk a couple of weeks back. Humblest apologies.
Paul Sanders.
Some of my best work is in the undo buffer.
modified 16-May-22 8:16am.
|
|
|
|
|
|
Yep, that's the one. I'm old enough to know better than to lecture people.
And thanks. Sig has reached stability at last
Paul Sanders.
Some of my best work is in the undo buffer.
|
|
|
|
|
|
You have to create an account to open that link
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Not here you don't. I read both for free.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
