|
Completely new. At my current job, they keep making noise about doing unit and automated ui testing, but once again, our alarming lack of personnel and complete lack of ability to do proper agile/scrum, capped off by over-the-top security restrictions prevents the team from adopting any tools to perform that kind of testing. It’s maddening.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Yeah, I've been there, done that, for DHS/CBP.
"Work smarter, not harder!" Oh, and you're not allow to write script for anything... 
|
|
|
|
|
#realJSOP wrote: I think I'm going to see if
Well dang, that'd be cool. Let me know how the wrangling goes.
And yes, Selenium, when I've played around with it, is temperamental.
|
|
|
|
|
This one: The Lounge[^]
Everything went as expected, except that one thing I can't fix myself and I don't know who can 
Apparently, someone deleted some DNS records so I can't hook up my custom domain name anymore.
It worked for DEV, TEST and another PROD service, but not the one they use first thing Monday morning.
The person I had on stand-by has access to pretty much all systems, except DNS.
Other people who weren't on stand-by and who might've helped went straight to voicemail.
Sent out an email to IT support saying these DNS records have to be added.
Let's hope they'll make it before 9AM Monday morning (yeah, right) 
|
|
|
|
|
|
|
It was you! couldn't remember who it was, thanks for that book...
|
|
|
|
|
Two points (I didn't read the book, just looking at Amazon page):
1. Multiplatform Assembly Programming - such thing doesn't exist. I am a bit skeptic when an author promises to learn me non-existent thing.
2. Many reviews are talking about "retro programming", which looks like a hobby and not something that can help in real work.
Again, this opinion is based only on the book review.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
