jawnv6

I picked that up during a steam sale along with the Toki's, I'll check it out. Thanks!

Thanks for the suggestion, I will!

I enjoy the general structure of Metroidvanias but most of them rely on combat mechanics for the micro-challenges in each room or boss. I like the exploration, backtracking, progression and unlocking previously inaccessible area.

But combat isn't the only mechanic that could be present there. There are examples like Ori and Toki where combat is de-emphasized in favor of movement/puzzles, but they're still 2D platformers.

I want to see a metroidvania game based on racing. I enjoy driving/racing games and would like to see those mechanics provide the micro-challenges for a metroidvania. Boss fights would be setpiece races, earning XP would be small things like a time trials, stunts, or precision driving. Unlocks like drifts, speed boosts, etc.

but... you had to go looking for that one, skipping over the part where you saw a bunch of waist-up pictures of a cartoon canine and got too hot and bothered to continue reading? it's not linked from the original article

great article. fun to see things like

Transmeta usually steers the conversation toward performance on DES algorithms or MPEG loops, tasks that play into Crusoe's (and Efficeon's) strengths. 'MPEG loops' got a lot more important in the intervening years

transmeta was right. their approach was better, it should have won.

I don't think the project is putting their best presentation forward, but the second image on the intro makes it pretty clear there's a .v/.sdc/.def file kicking around. Without any relevant tooling to develop, debug, or modify them, but it's clear the python is just shuffling deck chairs.

This seems like a pretty egregious misreading of the project?

Python isn't being lowered into silicon. It's a glue language for Boring Old Verilog that's been "compiled" into silicon since 1984.

chip.set('source', 'heartbeat.v')

The execution time is going to seem really zippy after the 8 week wait for the chips to be fabbed.

It's impressive but in practice, as a guide, it's very difficult to use. There is one path to follow with no overall map or routing to skip things. So to use it to figure out one tricky section often means reading 4 extra paragraphs just to find a landmark and trace from there to where you're stuck before you can follow along.

You're not a billionaire, why are you spending your precious time on this earth trying to lump them together with "middle class Joes" as if that absolves them of their history?

Perhaps Buffett doesn't have a singular genius for applying his wealth to charity. It's anti-democratic on its face to just surrender control of "what problems are solved" to a single person, regardless of the decision metric. Is it truly better for one person to control all of that on a whim? Even assuming the best of intentions, he may pick a disease charity based on a close association with a victim rather than any broad rational analysis. You're just hopping right on board with his unquestioned assertion "I'm better at picking," did you give that one any pause or just hopped right up to carry that water?

What are the problems that governments are 'often' poorly suited to solve? Would governments be more or less suited to deal with these issues if they hadn't been defunded to support the personal wealth and charitable whims of billionaires?

"What the Dormouse Said" is a classic, highly recommended.

Much more niche is "Race for a New Game Machine," highlighting the IBM design team responsible for the chips powering the Xbox 360 and PS3.

that may have been what they wanted to write. unfortunately they wrote something wrong and misleading instead. i understood what they wrote perfectly well and the implication therein isn't, somehow, my fault

no, you could not "always" find something useful to put there later. gross exaggeration

in addition to the complexities they add to every layer of the stack that ajross and alain94040 brought up, they're not all that useful in practice. i seem to recall that they'd rarely be over 50% utilized and the majority of instructions in the delay slot were nops

you sure about that link? he's talking about a core that didn't have SMT and is ranting, in general, about errata existing and wildly misrepresenting their impact

never mind that most errata are conditional until the ucode patch load, but that particular rant has nothing to do with HT

I fail to see how a dev talking about a wholly unrelated implementation from an entirely different vendor has anything to bear on this conversation unless you're just maliciously spreading FUD around the entire concept of random numbers.

Do you actually know if the instruction is faulting or delivering back non-random data ("sure it does...")? Is the non-random data 0's or something with a pattern like 0x9090? Does that match the Intel implementation's behavior exactly?

right, labor law is aware of "constructive dismissal," been a part of the law since, gosh, 1964?

oh right but this is ~google~ in the ~silicon valley tech industry~ so stodgy old concepts like "long settled labor law" still appear to be wholly unheard of by the average techie bootlicker

how is MESI "an abstraction"? why is it the only model proffered instead of MESIF/MOESI?

and "the top 16-bits are basically ignored" is a funny way to spell "general protection exception on linear memory reference in non-canonical space" but sure, guess we're just handwaving here

i legit don't know what you're expecting? your lie was central to the technical discussion and at no point did you acknowledge the error.

if you can't handle being called out for providing false technical information... don't hand out false technical information? seems easy. it's not, as you so desperately want, a personal attack to identify areas where you're misrepresenting the technology.

im curious, how did you want this to go? DT, incorrectly:"fences are required" jv6:"ah, well, hm, er, here's section 8.1.3 which doesn't mention fences at all and specifies two methods (neither of which is a fence) that ARE required to ensure correct operation" like can i even tell people the truth? or must your egregious misrepresentation stand without question for you to find the "tone" acceptable?

im sad i missed your edit, apparently filled with unhinged personal attacks, but ive limited my commentary to the technical details and it's amazing that you still claim some higher ground while steadfastly ignoring the subject matter, on which you are incorrect and misinforming others.

im not claiming to be a "better assembler programmer" im literally quoting the only relevant documentation on a tricky area where you were spreading lies charitably dressed up as half-guesses. if you hadn't barged in with some grossly incorrect theory about fences we wouldn't be talking at all. i still think lying and misleading while putting on airs of educating folks is worse than, uh, quoting documentation? are you thinking the documentation is being too harsh on your pet theory?

will you at least agree to stop spreading this dangerous misinformation? neither fence is serializing (like... you wouldn't want them to be...) and someone building a JIT around your guessing is heading towards an erroneous implementation.

bait? regardless of my tone, a memory fence is not required. no reading of the relevant documentation supports that, if you want to be wrong you're free to do so. but please don't pretend to educate others with wild uninformed guesses, that seems worse to me.

here's the documentation: https://software.intel.com/sites/default/files/managed/39/c5...

Section 8.1.3 Handling Self- and Cross-Modifying code

(* OPTION 1 ) Store modified code (as data) into code segment; Jump to new code or an intermediate location; Execute new code;

( OPTION 2 ) Store modified code (as data) into code segment; Execute a serializing instruction; ( For example, CPUID instruction *) Execute new code;

this doesn't strike me as contentious, there is no guideline that states a fence is necessary. you're possibly making the assumption that fences are "serializing instructions" and, well, again i'd question what documentation backs that interpretation up. is a sfence or lfence "more" serializing?

a memory fence is not required, as per my reading of the Intel documentation. i think you're just guessing and haven't actually written any SMC x86?

would you mind sharing what PRM sections back up this reading? maybe a careful re-read will help you figure out what "might" require a full fence.

you should probably check the Programmer's Reference Manual (PRM)

i mean, they don't try to hide this information? Section 8.1.3 gives two options that are guaranteed to work across future iterations of hardware. the sibling comment that assumes a heavy serializing like CPUID is the ONLY method is shooting from the hip and only really appropriate if you're playing tricks with what LA you're using for the write/read.

you'll probably want to skim "11.6 Self-Modifying Code" as well. SMC is guaranteed to work, not work fast. Most folks want that second one and blasting out icache entries is going to put a damper on that.

wasn't it generally agreed that the Gawker-destroying opinion probably would have been reversed if they could've kept it afloat for an appeal? the bar for "messed up" isn't where you'd think

It might? Your OP was very specific on the subject and you seem aware that the side is inappropriate: Few hard taps on the bottom detach the CO2 bubbles and cause them to all go to the top few hard taps on the bottom (not the side), few hard taps on the bottom of one (finger-tip with almost painful force)

The actual claim on the site: Claim: Tapping the side of a soda can will prevent its contents from foaming over when you open it.

I don't think you're as vehemently committed to rigorous fact-checking as your little anecdote would have us believe.

"the" VC? lol

Right, the article is chasing VC money. They have a calculator to see how far a VC dollar will take you called "VC Arbitrage". The author takes flights to SF specifically for VC meetings.

You're talking about a situation wholly removed from the article, why?

50% of VC funding lands in CA. 50% of that is on Sand Hill. So ~25% of all VC funding happens in offices in Palo Alto, the sheer efficiency of chasing a funding round can't be beat.

For an established serial entrepreneur with a proven track record, it can absolutely make sense to stay in an area you know. But I think that math really changes if you're going to be cold calling VC's, trying to wrangle meetings from 3 time zones away, get meetings bunched up to consolidate travel, etc. The overhead of redeye travel is relegated to a joke at the end, where's the "measurement" on that?

It's still incredibly disrespectful way to approach a community, and all of these replies ignore the thrust of my question about the expert re-upping after this ruse has been made apparent.

Comboy spread a lot of disinformation in the first post, like "I'm surprised there's still not much effort to make FPGAs more affordable and base everything on it." before the lie was laid bare. Looking forward to arguing with "FPGA experts" who harken back to that post as their primary source.

disclaimer should have been in the first post, not a reply to a reply long after the confident assertions over what a "storage" CPU must do.