Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

Bit level vs byte level

Name: Anonymous 2006-04-17 16:08

Am I correct in believing that video game consoles such as the NES used graphics and instructions at the bit level?  Why don't modern operating systems use instructions that are only a few bits rather than bytes?  You'd be doing the same operations at 1/8 the scale.

Name: Anonymous 2006-04-17 16:12 (sage)

Um.

Name: Anonymous 2006-04-17 18:28

>>1
How to say this... Things are good, you don't need to worry about them.

Name: Anonymous 2006-04-17 20:33

>>1
Holy shit you're right! You should tell Microsoft at once, maybe they have a job for you to rewrite Vista from scratch at 1/8 the scale!

Name: Anonymous 2006-04-17 22:05

>>1
I hate you.

Name: Anonymous 2006-04-18 1:11

Ignoring >>1's naivety for a moment, you must admit that the "There's plenty of memory and CPU power available" view has led to wasteful coding practices and standards. Examples: Games filling up multiple CDs with detailed crate textures, XML, Firefox's memory usage (ok, arguable), Adobe/MS Office products taking up to a minute to load.

Name: Anonymous 2006-04-18 2:05 (sage)

>>6
Everything should be written in assembly amirite

Name: Anonymous 2006-04-18 2:19

>>7
Fuck that. Everything should be voltages!

Name: Anonymous 2006-04-18 2:56 (sage)

It's not a question of assembly, but shitty coding.

But this is what the market likes. :(

Name: Anonymous 2006-04-18 4:58

>>6
XML
Fucking agreed, PoS of a language. A standard grammar processing tool supporting unrestricted languages would have been much better, but then it may be too complex for stupid magazines and managers to wank to so it wouldn't have been a business success. Business is about magazines and managers.

Firefox 1.5.0.2 has fixed some bugs and is not that bad; most of the memory is taken by the fast forward/backwards cache which can be turned off somehow I think.

Adobe is made of bloatware and fail.

New Microsoft products are made of bloatware and AIDS (digital rights infringement).

Name: Anonymous 2006-04-18 5:09

>>10
A standard grammar processing tool supporting unrestricted languages would have been much better
We have those. See lex, yacc, flex and bison.

Name: Anonymous 2006-04-18 7:23

>>11
But those suck and are hard to use. With XML we get wonderful things (but a little sucky) like DOM.

Name: Anonymous 2006-04-18 7:34

>>12
Which is good for what, precisely?

Name: Anonymous 2006-04-18 7:37

>>13
Good for the programmers, it is easy to use.

Name: Anonymous 2006-04-18 7:47

>>14
Have you ever used DOM? All it does is build up a tree, which you then have to parse programmatically. lex et al are a set of tools for automatic parsing.

Name: Anonymous 2006-04-18 7:50

DOM?

What exactly is it about the others that precludes them from having a DOM? I fail to see anything inherent in XML that makes it amazing for having a DOM...

Name: Anonymous 2006-04-18 9:02

>>16
It has DOM now, the others possibly do not.

>>15
Yes indeed, I wouldn't write a lexer for anything I'd consider using XML for, representation of data, that is.

Name: Anonymous 2006-04-18 10:58

RISC IS THE FUTURE, MAN!!

Name: Anonymous 2006-04-18 14:06

Hi, I use regular expressions to parse XML shit and non-XML stuff as I please, durrrrr

Name: Anonymous 2006-04-18 14:26

>>1
the nes used 8 bits instructions...I don't understand what you are trying to say. You can't simply change the number of bits each instruction needs...

Name: Anonymous 2006-04-18 17:45 (sage)

It has DOM now, the others possibly do not.

Uh... way to miss the point.

Name: Anonymous 2006-04-18 20:30

Why would you use XML for anything in the first place? It's ugly and you're better off using a lean regex library than a fat bloated xml library.

Name: Anonymous 2006-04-18 20:55

>>21
What point.

>>22
Because with XML, you can do pretty much anything with little work, and a lot of reading. All of it compatible with the latest buzzwords.

Name: Anonymous 2006-04-18 22:07

What point.

The question was "What exactly is it about the others that precludes them from having a DOM?"

You need to practice your reading comprehension.

Name: Anonymous 2006-04-19 5:18

>>24
Yes, and that does not matter in the slightest because they do not have a DOM *NOW*. Developing one would take many manhours and cost millions.

There is nothing that ties DOM to XML, except that it's been implemented.

Name: Anonymous 2006-04-19 5:19

>>25
Do you even know what DOM is?

Name: Anonymous 2006-04-19 6:19

>>26
The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. This is an overview of DOM-related materials here at W3C and around the web.

Hm, not entirely right IMO.

Name: Anonymous 2006-04-19 7:21

It's just a tree, that's all. It doesn't do anything. You just parse an XML document into a tree and call it a DOM.

Name: Anonymous 2006-04-19 9:52 (sage)

>>28
Don't forget the API!

Name: Anonymous 2006-04-26 1:17

>>1
The NES's CPU was a 6502-compatible, meaning it addressed everything (registers and memory) as collections of eight-bit bytes.  All opcodes in the 6502 are eight bits.  You have bitwise operators (AND, ORA, EOR) but they require full eight-bit operands.

The only instructions that operate on a bitwise level in 6502 are the set and clear flag instructions (SED, CLD, SEC, CLC, SEI, CLI, CLV)

The NES PPU (graphics) and sound hardware have registers wherein each of the bits within are dedicated to specific functions.  Accessing specific bits require the above bitwise operations.  However, the graphics data itself are held in normal 8-bit RAM and on 8-bit boundaries like all other memory and registers of the CPU.  With the exception of one area of memory in the NES called the attribute table, that is a collection of 2-bit values... but again, you need bitwise operations here.

Effciency in processing CPU instructions, for CPU design, lies in making the CPU instructions the same number of bits, and such principles apply in architectures such as MIPS, PPC, ARM, etc.

Name: Anonymous 2006-04-26 11:00

>>30
Yeah, all opcodes were 8 bits long on a 6502 (and variants), but most of the useful ones had one or two parameter bytes after that. And then there were the shift and rotate instructions.

Name: Anonymous 2006-04-26 14:40

No idea what anyone is talking about.  I'm planning on majoring in computer science, though.  Will they teach me this kind of stuff, or shove more Java down my throat?

Name: Anonymous 2006-04-26 19:36

>>32
Depends on what kind of uni you go to.

Name: Anonymous 2006-04-27 2:51

Oh yeah, forgot about ROR, ROL, ASL, and LSR

Name: Anonymous 2009-01-14 4:22

>>34
They operate on bytes and words.

Name: HAXUS THE SAGE 2011-10-07 0:32

Not /prog/ related. GTFO!

Name: Anonymous 2011-10-07 13:14

>>35
Bytes only.

Name: VIPPER 2011-10-08 8:19

byte
u mena ``octet''

Name: FrozenVoid 2011-10-08 8:25

>Why don't modern operating systems use instructions that are only a few bits rather than bytes?  You'd be doing the same operations at 1/8 the scale.
They do actually, its called microops(uops), and opcodes are decoded to be reassmbled as uops inside the CPU pipeline.
http://abinstein.blogspot.com/2007/05/decoding-x86-from-p6-to-core-2.html

Name: Anonymous 2011-10-08 10:38

>>39
They could have easily used SEXPs instead.

Name: Anonymous 2011-10-08 11:24

>>6
Why oh why do everyone keep bringing up FFs huge memory usage? It's in the past, now chrome is the king of memory usage.

Name: Anonymous 2011-10-08 14:30

>>41
Just wait 'til they finally release a 64bit version.

Don't change these.
Name: Email:
Entire Thread Thread List