Have you ever actually had a need to program in x86 directly?

>>57417697
yes, SSE optimization. GCC doesn't do a good job if you're not doing something trivial.

I guess I could have used those intel SSE wrappers, but they're basically just programming in assembly anyway.

>>57417697

No, the real advantage of knowing x86 assembly is to be able to reverse engineer and use software like IDA

>>57417697
No, but it sounds like a fun exercise in DOS.

Do the GNU binutils exist for DOS? I'd like to have something recent.

>>57417697
I am confused how virtualization and raw assembly stick together

>>57418565
It's useful for trying to figure out what the fuck is happening in your code when your compiler blows up, as well. I've had some absolutely insane shit done by clang.

>>57417697
Yes. I needed to access the contents of an encrypted iTunes backup, but no free stuff was able to do it. I had to download some shareware crap for which no crack was available. So I disassembled it via GNU debug utils and overwritten the "isRegistered" method (thanks Objective-C for keeping method names in the binary!) with "ret 0x01".

pretty much only if you need to write fucking viruses or reverse engineer WMM
i only know a few 6502 opcodes/operands anyways

>>57418745
6502 is slow but fun to program for desu

though fuck programming for the NES, that's anti-fun

yeah, I was low on ram on an old server so I wrote a web app in assembly, it was a simple forum but I did have thoughts of suicide later.

>>57418752
i dont know anything about ricoh 2a07 architecture. is it any different?

>>57418644
http://0x0.st/2jo.pdf

>>57417697
Yes. I'm a BIOS dev.

>>57418769
it's pretty much the same processor, it's just that it takes so fucking long to get anything to work

just getting a character to print is ass

File: 1463086386224.png (216KB, 338x400px) Image search: [Google]

216KB, 338x400px

>>57418782
I'm not opening that shit

>>57417697
>posts MIPS ASM

i aint falling for your trap OP

x86 doesnt make too much sense anymore
ASM's really only used for microcontrollers

>>57418790
how did super mario bros 2 aka the great game of all time work then

>>57418792
It's literally a pdf on compiler optimizations....

You can find another copy by googling "Dangerous optimizations and the loss of causality" if you want

>>57418789
Which virtual machine software suite are you programming for? I can't imageine any physical hardware needs BIOS nowadays since UEFI is the standard now.

>>57418802
very carefully

>>57418813
japanese asm wizards

>>57418804
alright I looked it up on VirusTotal. Looks legit.

>>57417697
Does "to pass a class" count?

>>57418818
but in all seriousness, the reason why it's so hard to program for the NES is that the documentation was pretty much done entirely from reverse engineering

the C64 was pretty much officially documented for everyone

>>57418565
in 2005 you would be called a skiddie for using IDA

>>57418806
BIOS is still used as a catchall term for system firmware, including UEFI. When referring to the old BIOS, people usually say legacy BIOS. However, software like SeaBIOS is actively in development and used in some systems in combination with coreboot as a simple alternative to the clusterfuck that is UEFI.

>>57418752
Oi, 6510 C64 asm is super fun and easy to learn. With memory-mapped IO you can do everything by poking the memory addresses, like displaying and moving sprites, collision check, hardware scrolling. It's a blast. NES, however didn't have that and you have to do the same things via ports, it's much more complicated.

>>57418806
But to answer your question, I don't program for virtual machines. It goes on real hardware.

>>57418869
Yeah, it always gets me when people call UEFI, BIOS

>>57418875
YES, that's exactly what i mean

the sega genesis has the same port bullshit and it made me gave up on learning 68000

>>57418877
I've still got a couple of BIOS machines, hell, my main PC is that old that is has it, the only thing that has UEFI is my second laptop.

>>57418901
The fun thing about that is that it could still be a UEFI system using exclusively CSM so that you never see any UEFI frontends and it still looks like a legacy BIOS. Unless your system predates the creation of UEFI, in which case, holy shit.

>>57418892
isnt 68k supposed to be the best asm of all time though

>>57418939
apparently so but the genesis is too hard to program for

i don't quite get how you're supposed to get past all the anti-piracy stuff

>>57418937
yep, my main machine is from 2010 and still kicking, the laptop I was talking about has a UEFI that's sorta disguised as a BIOS

68k best language. SuperH language comes behind it in #2.

Now fuck off

>>57418960
what's your build? My Q9550 from 2009 still kicks ass.

Only time was when taking an OS class. Also had to do a lot of reading x86 for a class on Performance and Optimization.

>>57418981
It's an old Pentium Dual Core E5500 system, I'm wanting to upgrade to a completely new system as you can probably guess, but hey, I was at least able to upgrade it to 8GB of ram a couple of years ago from the original 6GB

>>57418644
>I've had some absolutely insane shit done by clang.
Do tell.

>>57418892
You can write 68k for Amiga. It might take some time to learn all the copper and blitter stuff, though. Such a sophisticated piece of hardware.

Is the asm for modern PC's different nowadays than it was for 486? I only want to switch to Mode 13h and write cool graphical effects.

>>57419052
>Is the asm for modern PC's different nowadays than it was for 486? I only want to switch to Mode 13h and write cool graphical effects.
hell no, modern operating systems abstract stuff way too much

the cool thing about DOS is that it was barely an operating system

I did once. Actually still have the source code.

I wanted to make a really modular kernel that was just using BIOS functions. Worked fine until I got over the how-many-bytes-you-have-available mark for the MBR.

Then I wanted to have extended hard disk loading support (because more modern BIOSs have different interrupts for that). Problem was that this shit was so undocumented that at some point I just gave up.

Haven't been doing much assembly since then. I like languages like C, where I barely have to worry about the ABI.

>>57419064
>hell no, modern operating systems abstract stuff way too much
So even mode 13h programming would have to be done with an emulator, how crap is that.

>>57419147
thankfully, dosbox seems to be close enough for that most of the time

makes it easier to cross-compile, too

>>57417697
Yes, when writing a kernel.

>>57419165
Fuck off Stallman, Hurd is dead

>>57419286
this

why the fuck does the HURD still run on x86 only

>>57419316
Because no one cares.

>>57417697
It's good to modify after compiling. Don't write complete programs in it, that's fucking insane.

>>57419580
>modify after compiling
why would you ever do this? Are you trying to sneak vulnerabilities into a project?

>>57419809
optimizations, checking if it actually works

who the fuck writes raw assembly are you completely mental

>>57419866
>optimizations
Do you copy the code into inline assembly or something when you do this?

Are there many situations where there's a real difference (excluding SIMD optimization)? Modern CPUs really aren't all that impacted by changes in the assembly code, in my experience

>who the fuck writes raw assembly are you completely mental
people doing SIMD optimization, crazy low level shit (mutexes, etc.) and security vulnerabilities.

>>57419809
patch proprietary binaries

>>57420019
>crazy low level shit (mutexes, etc.)
I knew I was doing lowlevel stuff (mostly programming in C), but I wasn't aware that it was crazy.

>>57420080
You wouldn't do this after compiling. You'd only do this if you didn't have the source code.

>>57420093
There's a lot you can't do in C, because C is designed to run on pretty much any platform. Mutexes, swapping out the stack pointer (you can sort of do this with longjmp), software interrupts, setting certain hardware states. This kind of stuff comes up if you want to make an OS.

There's also a lot of security exploits, like stack execution, which you can't do in C.

when I say that you can't do these things in C, I mean they're undefined behavior. You might be able to get them to work, but they're not correct.

>>57420193
Isn't this problem fixed by using asm() though?

>>57420209
Then you're writing in assembly, not C. Is asm even in the C standard? I thought it was an extension.

>>57420238
it is, in fact i think doing it is pretty idiotic, but i guess it's still a solution

>>57420254
What's the alternative? How else are you going to write a mutex?

There are some language extensions that use function call syntax to access hardware intrinsics. These don't exist on all platforms though.

>>57420193
>You wouldn't do this after compiling. You'd only do this if you didn't have the source code.
Which is the case with most proprietary binaries you get. Last time I checked NVIDIA didn't release their drivers source.

>>57420370
so... you didn't answer why you would modify after compiling, which was my question.

>>57420193
>when I say that you can't do these things in C, I mean they're undefined behavior
No, that's not true. They are merely not defined by the C standard. But there are other standards that apply here.

>>57420396
I meant for that to apply to only the last paragraph about security exploits. It sounds pretty dumb, the way I phrased it.

>>57418767
lies.

>Asks about x86
>OP image is MIPS
?????

>>57420620
I was wondering why I didn't recognize any of those opcodes. I thought he was just delving into the horrible obscure and mostly deprecated opcodes in x86, like enter and loop.

>>57419165

you don't need assembly to write a kernel

>>57421077
Depends on the platform. For example, how do you want to switch to Long Mode if you cannot address registers specifically?
>inb4 u don't

>>57418767
nobody believes this shit
nobody programs in assembler anymore
if they know it they know it all
they don't "dip in" - as in (here) "yeah I rattled off an assembly program to do x" or "yeah I was in a hotspot & I just plugged in macroassembler and wrote" 1. it's not needed. 2. nobody does that- people who "know assembler" know the whole thing and more -- that is, people who USE assembler. This is not a randomly incremental thing.

>>57417697
if anyone here "write assembler" - yeah they did x years ago as part of college or worked in embedded systems, or the work in it 100%, full time. assembler programmers aren't hobbyists it resembles nothing in the real world it is the atomic scale

>>57418939
stunned me to find out that the 6502 chip was something lke $5 and the z80 was $600 (on launch) - why did 1 perpetuate

the 6502 was cheap and why wasn't it the major useage?

>>57421457
I guess because of RISC - memory was scarce back them.

>>57421457
6502 is SLOW

>>57419052
is there a good way to cross-compile (i already know about recompiling GNU binutils to target the 68000) but also "automate" the testing?

when i was fucking around with the C64, i had a "test" make target that would assemble and automatically launch the program in an emulator

>>57421457
>and the z80 was $600
no it wasn't, where the fuck did you get that from? they sold at about the same rate you listed for the 6502

>the 6502 was cheap and why wasn't it the major useage?
apple, atari, commodore and a myriad of other platforms weren't enough? the 6502 was wildly popular, but like >>57421619 said it was a fucking toy and slower than shit, not to mention it didn't have the compatibility edge of the Z80

>>57421594
what are you even talking about? both camps carried the same gimped memory ceilings

>>57423061
>what are you even talking about? both camps carried the same gimped memory ceilings
RISC opcodes have a fixed length. CISC are usually more compact.

>>57418745
I know four op codes and that's enough to program anything computable ^^

Define "need". Most shit I write is for fun, not something I need to do. I've written a small bootloader that reads some crap off a floppy disk and switches to protected mode before in x86 assembly, and that is something that you can't do with C (at least not without inline assembly), but strictly speaking, that is not something I needed to make. I just felt like making it.

>>57419286
>>57419316
You two are fucking retarded.
You do realize that the Linux kernel also contains x86 assembly too, right?

Or did you think I meant writing the ENTIRE kernel in x86 assembly? no that's fucking stupid.

>>57421077
Yes you do you stupid fuck. Educate your fucking self.

File: 7BIlFccT.jpg (17KB, 400x327px) Image search: [Google]

17KB, 400x327px

>>57423187

>>57421077
You do need some assembly. You can't do a context switch without saving off registers, which you can't do in pure C.

>>57423238
>inb4 you don't need context switches

>>57423095
you can literally program with only the "mov" operator, actually

File: 14938383_10208870000081337_5472442231651974051_n.jpg (23KB, 645x395px) Image search: [Google]

23KB, 645x395px

>>57423334

>>57423187
yes and that's horrible

>>57423334
>you can literally do any 2D graphics related thing with only the brush in MSPaint, actually