Slashdot Mirror

ARM is actually quite old and suffers from a number of architectural shortcomings which can't be fixed for compatibility's sake. x86 gets a lot of flack for being complicated, but as ARM dates back to the 90's and has had a ton of extensions hacked in over the years, it isn't actually the minimalist, efficient powerhouse people think it is. You may ask well ask why the mobile market needed ARM when we had perfectly good x86 chips available.

I'm not a hardware guy, but since encountering the Visual 6502 project a few weeks ago, I've been looking into ISA design and how processors have evolved over the decades. I've currently designing my own 16-bit processor using SuperH and RISC-V as inspiration. Even to a newbie like me, it's very obvious how modern and clean the RISC-V design is, how compact the instruction set is, and how much potential it has for fast, power efficient cores.

Also note that embedded system developers don't really care about legacy support. If RISC-V is cheap, efficient, and fast, it could easily compete with ARM, at least in the 32-bit market segment.

I don't want to enter the high-level debate here - I'm not qualified (and that's not sarcasm) - and I do know that this example doesn't really mean anything, or add to the debate, but:

Watch this:
http://www.visual6502.org/JSSi...

then watch this:
https://www.youtube.com/watch?...

and think about them for a minute. It never fails to make me stop and wonder.

http://blog.visual6502.org/2015/11/the-visual-arm1.html

Who RTFA anyway? A badly edited summary should be enough for anyone (tm).

Most people don't care because they aren't even interested in computers.

If you talk about Slashdot readers then they have all read enough articles to know that open source itself doesn't provide a perfect protection against backdoors.
You also have to read the source to see that no backdoors are put in place, and you need to build the executable to make sure that the version you are running isn't built from a version of the source with backdoors in it.
Now, assume that a processor like this becomes as mainstream as Intel and AMD CPUs, do you really think it is impossible to manufacture an FPGA with backdoors?
For people to use the CPU it has to reach a stable point at some time. A stable CPU and a stable toolchain to build it will have a known layout and can be targeted with backdoors in the FPGA in the same way the CPU would have backdoors.

So knowing that it isn't sufficient to just have an open design but that you also need to verify the hardware, why just not just skip the open part and verify the hardware directly?
As a Slashdot reader you should at least have seen the reverse engineered 6502 visualizer. It is a much simpler CPU, but it has been reverse-engineered and its function is emulated in javascript with the transistors of the chip lit up. No room for backdoors there.
A similar analysis has been done for the M68000, I couldn't find the slides from the presentation on it I saw, but here is a pdf with a rough overview that doesn't go into as much detail.

Since you need to do that kind of analysis of the FPGA anyway it seems to me that the open source CPU part is more about "Not Invented Here" than about protecting against backdoors.
That means that most people who you would think would care. They like the idea of it, but not this implementation since it isn't the one they did themselves.

The only way to truly understand C is to read the CPU circuit design on which the application will run. Otherwise you are only assuming what the CPU will actually do with the opcodes generated during assembly. See 6502 opcode 8B (XAA)

> Other people have done much more reverse engineering of the chip, down to the gate level even.

See: http://www.visual6502.org/JSSim/index.html

The Atari 2600 uses a 6507, which is a 6502 die in a smaller package—fewer address lines pinned out.

The Ricoh chips in the NES use an exact copy of the 6502 die layout, plopped in a larger chip. Go have a look. You can see the 6502 portion in the lower right hand corner. (Here's the original MOS 6502 for reference.)

When I say exact, I mean darn near exact: They differ by 5 transistors, apparently, representing a surgical excision of decimal mode.

So yes, the part number is technically not 6502. But, that's really a technicality. It's the same layout and everything, packaged in an SoC. The relevant part to the programmer is that they can pull up a 6502 opcode chart / timing chart and start crackin' away and it'll work just as they expect, undocumented opcodes and all.

The Atari 2600 uses a 6507, which is a 6502 die in a smaller package—fewer address lines pinned out.

The Ricoh chips in the NES use an exact copy of the 6502 die layout, plopped in a larger chip. Go have a look. You can see the 6502 portion in the lower right hand corner. (Here's the original MOS 6502 for reference.)

When I say exact, I mean darn near exact: They differ by 5 transistors, apparently, representing a surgical excision of decimal mode.

So yes, the part number is technically not 6502. But, that's really a technicality. It's the same layout and everything, packaged in an SoC. The relevant part to the programmer is that they can pull up a 6502 opcode chart / timing chart and start crackin' away and it'll work just as they expect, undocumented opcodes and all.

The Atari 2600 uses a 6507, which is a 6502 die in a smaller package—fewer address lines pinned out.

The Ricoh chips in the NES use an exact copy of the 6502 die layout, plopped in a larger chip. Go have a look. You can see the 6502 portion in the lower right hand corner. (Here's the original MOS 6502 for reference.)

When I say exact, I mean darn near exact: They differ by 5 transistors, apparently, representing a surgical excision of decimal mode.

So yes, the part number is technically not 6502. But, that's really a technicality. It's the same layout and everything, packaged in an SoC. The relevant part to the programmer is that they can pull up a 6502 opcode chart / timing chart and start crackin' away and it'll work just as they expect, undocumented opcodes and all.

If you're really interested, by now the old 8 bit computers are basically documented down to the last transistor. The 6502 certainly is: Visual6502. The few observations in the "article" hardly scratch the surface.

There's a group that simulated the entire 6502 and 6800 logic (not the electrical properties of the chip, though).

http://www.visual6502.org/

They seem to be at an impasse in the 68000 development though.

well, my esx vmware can emulate 10000 BBC micros.

BULLSHIT BINGO!!! VMware can not emulate a CPU of completely different architecture!

That's very waterfallish and not very agile of you.

The only way to get the BBC Micro to webscale is to start with a farm of VMs that all run the 6502 emulator in Javascript. Because frameworks and abstractions and vendors of cloud services tell you so.

And the best thing about using the 6502 is that you can even run it in JavaScript!

Had the software been around when I used a C64 (when they were the state of the art) . .

What do you mean? C64 still is state of the art . . . for 1982.

On the other hand, a clever hack borders on being timeless - for example and inspiration if nothing else.

Certainly in a time of ever greater bloatware it can border on mind-blowing to consider what people used to do, and some still do, in handfuls or hundreds of bytes: The Puzzle

Visual Transistor-level Simulation of the 6502 CPU

http://www.visual6502.org/JSSim/ in action.

Since we are talking about implementing 6502s in questionably efficient ways, it seems like a good time to plug http://visual6502.org/. Efficient? No. Logic-accurate emulation of a 6502 implemented in javascript based entirely on photographs of a decapped 6502 die? Fuck Yeah.

In other words, he's spending a million CPU cycles to simulate a single gate in the most roundabout way possible.

No, "the most roundabout way possible" would involve running that Java virtual machine on a Javascript-emulated 6502 processor (and there's really no limit to how many other layers of emulation you could stack on, especially considering that our whole physical universe is most likely a simulation itself).

Not to worry! Thanks to the power of javascript and web2.0, you can again await the day when we'll be able to push a 6502 into the realm of the megahertz!

(Please note, above linked project is actually pretty fucking cool: "In the summer of 2009, working from a single 6502, we exposed the silicon die, photographed its surface at high resolution and also photographed its substrate. Using these two highly detailed aligned photographs, we created vector polygon models of each of the chip's physical components - about 20,000 of them in total for the 6502. These components form circuits in a few simple ways according to how they contact each other, so by intersecting our polygons, we were able to create a complete digital model and transistor-level simulation of the chip.

This model is very accurate and can run classic 6502 programs, including Atari games. By rendering our polygons with colors corresponding to their 'high' or 'low' logic state, we can show, visually, exactly how the chip operates: how it reads data and instructions from memory, how its registers and internal busses operate, and how toggling a single input pin (the 'clock') on and off drives the entire chip to step through a program and get things done."

It is, however, the case that this might not be the fastest way to execute 6502 instructions...)

Hey, what happened to all the Apple fans saying the Motorola chips where better?

I don't know, but this is surely cool:

http://www.visual6502.org/

The 1970's called, it said you are low tech. Here's an example of a single TTL board from a VAX. There must be about 300 individual TTL chips from the 7400 series on it (where one chip has 4 nand on it, etc). The left 29 boards in this VAXare the cpu.

It is very noble to build your own CPU architecture with your own instruction set, however building CPUs out of gates in individual chips is just an exercise in wasting money when you can do the same thing on FPGAs, like the guy that built an entire Cray-1 on an FPGA development board. A more impressive project, the visual 6502 in javascript, made by scanning the actual chip and rebuilding the circuit out of individual transistors on the die, proves you don't even need hardware.

This reminds me of my Mac days. Got a problem? Blame a plugin. It's can't possibly be the app's fault.

Sorry, but I've done all kinds of experiments, including wiping out all plugins and extensions, and I still have major memory leak problems. Typically, after 10 minutes of browsing, my browser idles around 350MB of memory usage, which is when all the freezing problems (presumably garbage collection) begin to rear their ugly head. If I look at "about:blank", memory usage usually goes down to a mere 250MB. I have no doubt that the type of web sites people visit might be triggering the leaks, so individual results may vary.

Incidentally, does Firefox use a multitasking garbage collector? Regular freezes every 10 seconds drive me nuts, and those issues would likely go away if the memory manager was improved. The regular freezing is my biggest problem with Firefox, and has been bugging me for over 3 years. This problem has never improved one bit since I started having the issue in a late release of FF2.

It's not like this is exclusively a Firefox problem, too. There's a Javascript-heavy web site I've visited that makes Chrome suck up 600+MB of memory before the browser crashes. No other browser I've tested, including Firefox, has a problem with that site.

> There was actually an area of silicon that could not be used because there was an electrical outlet on the wall that they needed for something in the office, so they just didn't draw on that part.
Being curious, I just had to look at the actual chip layout in the online simulator to see if this was true. You can see a pair of rectangular voids left of the center, near the edge, the lower of which seems to have the right dimensional ratio to have been a space for a wall socket.

It's fascinating to hear the lost bit of engineering history that explains something would otherwise have forever remained a mystery. Somebody should forward this anecdote to the visual6502.org guys.

Yep.. Space Invaders, too.. SIGGRAPH talk: http://www.visual6502.org/docs/6502_in_action_14_web.pdf

Reverse engineer a simple CPU? That's so elementary.

Indeed it is. And why not emulate it at the bare metal level in JavaScript, while you're at it?