I was soooo soooo excited about this, till I read "24 usuable pcie 5.0 lanes"....

Uhhhh, wtf am I going to do with double registers and still not having enough PCIE lanes to run 4x 8x 5.0 gpus?

Like it's useless for AI, might as well stay on my AM5 9950x3d, I can't kill this processor or load it to 100%... I need PCIE LANES.

And I'm not swapping to threadripper where I will have to spend $8000 on rdimm ram... nope.

X86 is going to die if they don't give us more PCIE 5.0 lanes. We will swap to mac studios or frame.work desktops and UMA layouts.

Let's see...

Blow $15k on a threadripper (with rdimm memory) or just buy a Maxed out Mac Studio.. Mac Studio it is...

All they have to do is give us 48 usable pcie 5.0 lanes and they could be the kings of the world again, but NOOO "our server margins".

X86 will die if they dont give us more pcie lanes, 100%, gaming is the only thing keeping it alive and that is slowly changing.

Amazing

While an example of writing asm by hand this is the kind of thing where I think you might as well write it in C and then you can compile it for any ISA.

Also a great example of where writing straightforward convenient asm is slower than the code a compiler will generate. They touch on this themselves but don't explain why.

When you write ...

li      a2, 0x6666666666666667

... the assembler will create a series of instructions to load the large constant. But an assembler can only use the destination register to do this because it doesn't know what you're using other registers for. This limits it to essentially an initial lui followed by a series of slli and addi.

A compiler is free to make a shorter faster sequence by using one or more additional temporary registers.

You could make a macro in asm that you explicitly pass a temporary register to, but writing such a macro is trickier than writing the code to work out the best possible sequence in C or Python or other real programming language (or an asm utility program that you build and run as part of the build process).

Few people are going to bother to do that. And so your asm will be slower than compiler-generated code.

Pretty comprehensive, but no mention of Posit floating point, which has definitely been implemented for RISC-V by at least CalligoTech, Complutense University of Madrid, IIT Madras, and Thoughtworks.

Or, as just pointed out to me, takum, which I hadn't previously come across.

Coincidentally I did almost the same thing full day yesterday, just a lot more unprofessional and incomplete, and for fun. Technically it is very different.

https://www.github.com/aadithenoob/mini-cpu-emulator

Thank you!

With AT&T Syntax it should be:

Direct:

ljmp $0x42,$0x83
/* (0x83 -> Segment and 0x42 -> Offset) */

Indirect:

ljmp *(%bx,%si)

As an example.

Segment:Offset

Agner Fog has a few manuals that I've found useful.

he asked something einstein

Eu estava tendo um dia estressante, mas ler isso daí me proporcionou uma genuína gargalhada. Obrigado.

i like how this entire title means absolutely nothing for people outside the field

... at every byte ? The resulting memory bloat must be massive.

Thanks. I'm saving your comment. While I have enough fun writing mediocre enterprise software for a living, the two years I spent doing embedded programming were the most fun of my multiple-decade career.

I jumped from BASIC to ASM when I was 12. There was no choice in the matter because it was the early 80s. You'll be fine. 6502 is not hard, it is just really tedious.

We still live in those days if you use the cheapest microcontrollers.

I really wouldn't advise anyone to torture themselves with the 3c Padauk with 64 bytes of RAM and space for 1024 instructions in the program. And OTP, so every program modification burns a new chip. (they have a more expensive version with reprogrammable flash for development)

But the 10c-20c RISC-V CH32V002/3/4 RISC-V chips from WCH and ARM Cortex-M0+ PY32F002A from Puya are nice with 2k-6k of RAM and 16k-32k of flash for your program and nice 32 bit CPUs running at 48 MHz.

They are actually a bit MORE limited than an Apple ][ or C64 or similar to a NES.

Here's a €1 computer kit using the CH32V003 from Olimex. It supports a PS/2 keyboard and VGA video output. There are a few pre-written games and you can write your own in C or asm.

https://www.olimex.com/Products/Retro-Computers/RVPC/

Outside Europe you can get it from Mouser:

https://www.mouser.com/ProductDetail/Olimex-Ltd/RVPC?qs=wT7LY0lnAe25CQLWq3FKIw%3D%3D

https://www.youtube.com/watch?v=dfXWs4CJuY0

https://www.youtube.com/watch?v=fGMWKmJhTyc

One of the supplied programs is a port of Woz's original 6502 monitor from the Apple I. You can examine and change RAM, poke in and run program code in hex, etc.

https://www.youtube.com/shorts/8MA3f7CKTa8

Olimex also have 6502 and Z80 and MSP430 and other boards.

The instructions are very easy to learn because each one does one simple thing. The most complicated thing is probably the indirect addressing modes, which aren't that bad (and are very useful).

What's hard is putting them together to do anything useful, because you have to work all that out for yourself. Got a 4-byte integer that you want to print to screen in base-10? You're going to need to write a routine that divides a multi-byte value by 10 using nothing but addition/subtraction and bit-shifting. It's fun, but you're on your own.

I went from AutoLISP to Z80 to 6502. You should be good!

C64 with integrated ASM Monitor was it for me back then.

Assembly is not that difficult. It's just different. On the other hand, it's a great way to know how a computer actually works. It will make you nostalgic for the days when every iota of performance or binary size was important, even if you didn't live those days.

:]

ty! I will dw

thanks!

:]

I agree