Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: X86CSS – An x86 CPU emulator written in CSS

lyra.horse

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#71

Post by rebane2001 »

antonvs wrote: post #69
rebane2001 wrote: post #33

Earlier quoted context omitted.

8086 is x86 https://en.wikipedia.org/wiki/X86

The point is that the 8086 doesn't have anything close to the instruction set now referred to as x86_64 or even x86_32. Asking which it is is asking which instruction set it implements. The answer is that it implements the 8086 instruction set. Saying this is an "x86 CPU emulator" is misleading, even if technically an 8086 is an example of the x86 family. To avoid the misleading ambiguity you'd have to say something…

I think x86 is still good because it's easily understandable. If I say it's an 8086 emulator, people who aren't familiar with the 8086 aren't gonna go "oh so like an older version of the same x86 on my computer". And "Show HN: CSS program that emulates a CPU that's a member of the x86 family" doesn't roll off the tongue.

I don't think calling it x86 is misleading, and this is coming from the perspective of someone who dabbles in rev and pwn of x86.

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#72

Post by sgjohnson »

jamal-kumar wrote: post #70
sgjohnson wrote: post #58

Earlier quoted context omitted.

They probably did, and just determined that it would be fun. The other week I had a fun project to implement IPv6 support in TempleOS. I did stop to think whether I should, and determined that absolutely not. I asked Claude to start planning on doing it. It started referencing ZealOS, which is a fork of TempleOS and already has a functioning TCP stack. That's when I determined that it would no longer even be fun, bec…

wasn't a lack of networking what made it a temple, untouched by the influences of the corrupt internet or something like that? idk I'm not like a Terry Davis scholar by any means but I always figured he did that limitation with some kind of reason in mind

Me and some friends of mine thought it would simply be funny if we gave the temple just IPv6 (no v4) support.

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#73

Post by senfiaj »

0x7cfe wrote: post #59
senfiaj wrote: post #54

I have mixed feelings. On the one hand, it's impressive, but on the other, it's concerning that CSS is turning into "JavaScript 2".

Now we can embed a cryptominer on a page even with JS disabled! /s

Interesting idea. This will be useful only when the CSS communicates with a server. Maybe it can make requests indirectly by setting background image URLs or something and send data piece by piece for each byte. Not sure.

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#75

Post by namuol »

mbreese wrote: post #63

This is a cool demo, but it tells me that CSS might be too complex now. Why should you be able to emulate a CPU with a styling language? I’m not sure what you get by using a Turing complete language for visual styling.

Less JavaScript is a bad thing now?

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#76

Post by namuol »

Predictably, all the same people who bemoan JS ubiquity feel the need to express their distaste for advances in CSS in this thread. Nobody is actually doing stuff like this in real applications, it’s just a demo, for fun.

I get the feeling some people just hate the web.

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#77

Post by Dylan16807 »

rebane2001 wrote: post #34
Dylan16807 wrote: post #20

> A hover-based clock, such as the one in Jane Ori's CPU Hack, is fast and stable, but requires you to hold your mouse on the screen, which some people claim does not count as turing complete for whatever reason, so I wanted this demo to be fully functional with zero user input. That hover clock post is from 2023 and the "some people claim does not count" post is 2022. They were probably talking about the ones that m…

I wasn't sure whether to address the disconnect in the FAQ - I wanted it to be short and readable. The idea is that, since a long time ago, there has always been demos that prove turing completeness and other programmy qualities in CSS, but that which people dismiss as requiring user inputs. The ones around by the time the comment got made were definitely at the "keep on clicking on the same spot on the screen" level…

> essentially just providing a clock

"providing a clock" is not something to dismiss though. Arithmetic plus looping will give you a Turing machine, so you do need both or you're just showing the ability to do arithmetic.

And a proper Turing machine doesn't need an extra line of template html for each iteration. It's much easier to forgive finite memory, since a small amount of memory can go for billions of years while an iteration limit runs out fast.

This one passes all the bars, but I do think the bars were overall legitimate.

> many still claim that even as much as hovering your mouse on a specific part of the screen makes css not a programming language.

That bar is pretty silly.

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#78

Post by rebane2001 »

Dylan16807 wrote: post #77
rebane2001 wrote: post #34

Earlier quoted context omitted.

I wasn't sure whether to address the disconnect in the FAQ - I wanted it to be short and readable. The idea is that, since a long time ago, there has always been demos that prove turing completeness and other programmy qualities in CSS, but that which people dismiss as requiring user inputs. The ones around by the time the comment got made were definitely at the "keep on clicking on the same spot on the screen" level…

> essentially just providing a clock "providing a clock" is not something to dismiss though. Arithmetic plus looping will give you a Turing machine, so you do need both or you're just showing the ability to do arithmetic. And a proper Turing machine doesn't need an extra line of template html for each iteration. It's much easier to forgive finite memory, since a small amount of memory can go for billions of years whi…

clock != looping, those examples already loop (dont need a line per iteration), but just dont have a built-in clock

and requiring a clock is imo dismissable, because pretty much all modern technology needs a clock too (either from the power grid, or from a hardware component designed for it)

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#79

Post by Sesse__ »

rebane2001 wrote: post #61
btdmaster wrote: post #60

Very cool. The horsle demo made me think, how hard would it be to add a virtual memory address (or a non-8086 RAND instruction) that returns a random byte (that would allow it to pick a random value and get a standard wordle working in principle) I see CSS random() is only supported by Safari, I wonder if there's some side channel that would work in Chrome specifically? (I guess timing the user input would work)

It's really easy, I was considering adding it. The easiest way is to make an @property that's animated at ridiculous speeds that can be sampled to get (sort of) random bits.

Or use a cycle timer and run a PRNG from it.

Or wait for us to launch random() :-) (It's in development, available if you enable a flag)

Re: Show HN: X86CSS – An x86 CPU emulator written in CSS

#80

Post by notepad0x90 »

Leszek wrote: post #18
notepad0x90 wrote: post #16

Earlier quoted context omitted.

Can an argument be bade that CSS only exists becuase javascript failed to develop a styling component to displace it? I like to think webassembly is the right track. But ECMAScript and CSS alike need(ed) to devolve into a simpler byte-code like intermediary language syntax. Browsers supporting complex languages has always been a bad idea, what they need to support is capabilities, and access and security primitives.…

The complex parts of JavaScript are the semantics, not the syntax. You could reasonably easily spec a bytecode for JS to get rid of the syntax part, but nothing would change in the complexity (almost all modern engines parse to bytecode as the first step and operate on bytecode from then on). If you wanted to implement JS in wasm, you'd either need a bunch of wasm extensions for JS semantics (dynamic object shape, pr…

I admit I don't have depth of knowledge with how JS and Wasm work behind the scenes, but you can already compile JS to wasm. Forgive the ignorance, but what am I missing here? When you compile JS to wasm, aren't the semantics and language behaviors already addressed?

My understanding was that things like DOM manipulation APIs would need to be (and are) exposed to the WASM runtime so that the JS-to-WASM compiler could do all the right bytecode "linking".

My idea is that if JS itself was require to in WASM, and native JS support didn't exist, the complexity in browsers would be reduced dramatically. And developers will be free to use different languages. Browsers will focus on APIs instead of language semantics. no more V8!

Post reply on HN