For a start, that's effectively the premise it's sold on. And for another thing, if it's not contributing to the kind of thinking that would help with that job, what is it other than another esoteric game?

In my experience it’s designed around a make/build/experiment pedagogical approach, not as a bootcamp system to get kids into programming careers

Just as you can say whatever you want, but facebook/twitter/reddit/whoever is not required to give you a soapbox, you can download this software and make whatever changes you want, but nobody is required to give a shit about your proposed changes.

News to me.

If HTML had <inline> <block> <column> <row> or <grid> tags, sure. But CSS determines the layout via display/position properties.

<div> is block

<table>,<tr> and <td> are your grid, row and column.

CSS improves on describing layout with positioning but HTML was still doing that before CSS even came along.

> explicitly and implicitly describe the layout of an HTML document.

No, this doesn't happen.

> In fact, "HTML" itself is an acronym (HyperText Markup Language)

Duh.

> in which the "Markup" describes the function of HTML to "mark up" text in a similar way that editors once did in the print industry, describing which parts of the text should be bold, italicized, etc. or divided up and in what way.

Which has fuck-all to do with the layout.

But is there any reason that google might have that they feel is legitimate?

For example, delaying releasing source until they've had a chance to update all the pixels with security patches might be good from their perspective, to reduce zero-day exploits for people they are supporting.

Ransomware gangs, etc still get red carpet service.

The motorola / GrapheneOS partnership gives me some hope though. Maybe when the pendulum swings back in 2028, the US will pass consumer protection laws, and we’ll have the right to import devices that allow open ROMs, and demand they be supported by cell networks.

(I doubt the moderate democrats would support this, but I’d guess the DSA candidates could be convinced to.)

The US recognizes exactly 3 types of intellectual property: copyrights, patents, and trademarks.

There are also, of course, trade secrets, but if you didn't surreptitiously gain access to the information and didn't sign any NDA, that's not something you have to worry about.

> as always, nuanced discussion will get lost in clickbaity headlines

Well, yeah, but if a human didn't use enough skill and judgment in creating something, the article is right. He won't be able to copyright it or patent it, although he could conceivably keep it secret.

But this is precisely the context of the original webpage: someone writing code at your company and your company not having copyright of that code. Almost everyone that works for any tech company signs an NDA, and code in private repos is just that: private. So even if said intellectual property (AI-written code) is not copyrightable, it's still a trade secret.

This is doubly stupid because I've worked at plenty of companies where we would routinely generate code (using macros or transpilers, or what-have-you), and that code is also not technically copyrightable.

It's only a trade secret as long as the company takes reasonable steps to protect it, and as long as what is being protected is a reasonable thing. Even if the code is legitimately a trade secret, if an employee publicly says "That code looks to me almost exactly like this GPL software" then (assuming the employee is correct) any court would take a dim view of a court case against the employee, because stealing shit is against public policy.

> This is doubly stupid because

No, that part really isn't. Trade secrets are about general business stuff, and as long as the company isn't asking you to help them hide evidence of malfeasance, they can ask you to keep any stupid shit secret.

Someone else!

All they have to do is show it's close enough to code that was swallowed during training.

Songwriters have been successfully sued for many decades for creating songs that are too close to songs that they probably heard.

Once this line of reasoning gets applied to code, all hell will break loose.

The notion of “your work is too similar to mine so I get to take ownership of it from you” is a very recent invention that has done more harm than good to human creativity, and if AI is the instrument of that invention's demise, then I look forward to it.

That notion only applies to patents and trademarks, and it seems highly unlikely that it would ever directly apply to copyright.

It may seem like the notion applies to copyrights, but it really doesn't. Independent creation is, and has always been, a solid defense to claims of copyright infringement.

That is why, when Phoenix Technologies reverse-engineered the IBM PC BIOS, they had two teams -- a team that took apart the original and documented the functional features (which have never been copyrightable) and a second team which took the description of the functional features and wrote new code.

The issue with songwriters has always been that, for civil laws, it's hard to prove a negative. How can you prove you never heard that song? Especially when it got a lot of radio airtime.

Now, how do you prove that your AI didn't ingest copyrighted code and then regurgitate it. Obviously, you can't.

> if AI is the instrument of that invention's demise, then I look forward to it.

Any court ruling that you would find beneficial for code copyright would mean that a human could have two windows open on their computer and cut and paste from one to the other and claim independent invention. That seems unlikely to be a good result, and also seems unlikely to come to pass.

You literally just gave an example above of that notion applying to copyright. There's no mere “seem like” at play here: the litigious music IP owners suing the pants off of musicians know full well that precisely zero musicians (least of all commercial ones) exist in a vacuum, and that's indeed the basis for the success of their litigiousness. Even if you can somehow prove you've never heard a particular song, You Live In A Society™ and that existing intellectual property's influence on society in turn influences subsequent creators.

There is, in other words, no such thing as true “independent creation”.

> Any court ruling that you would find beneficial for code copyright would mean that a human could have two windows open on their computer and cut and paste from one to the other and claim independent invention.

Don't threaten me with a good time :)

No, I literally did not. The difference may be subtle, but it is real, as I explained.

> Even if you can somehow prove you've never heard a particular song, You Live In A Society™ and that existing intellectual property's influence on society in turn influences subsequent creators.

And many musicians have won copyright cases, because their shit wasn't similar enough.

> There is, in other words, no such thing as true “independent creation”.

Which is why the whole enterprise is heavily fact-based. Seriously, think about it. If copyright is to have any teeth at all, then there has to be some line that can be crossed.

> Don't threaten me with a good time :)

Ah, I see where you're coming from. Well, I hate to break it to you, but the chances of AI eviscerating either copyright or patent laws are approximately nil.

And many musicians have lost copyright cases, because — per my point — their shit was similar enough by complete accident, because

1. We Live In A Society™ and therefore are constantly exposed to all sorts of things we don't consciously remember 5 minutes later but which stick around subconsciously, lurking for your next “Eureka!” moment; and

2. Musical genres (especially the mainstream ones) tend to coalesce on rather limited sets of chord progressions and rhythms and such, so it becomes more and more difficult to write songs that fit within that genre without accidentally “plagiarizing” some other existing song in that genre (or a related one).

That is fine. You do you.

But, again, if such property exists, then a line must be drawn.

Given the legal requirement to draw such a line, obviously some courts will sometimes get it wrong.

I understand you think you're making a cogent argument against intellectual property because the very concept requires drawing of the line, but no, you're really not.

If you come knock on my door to sell me shit, you're fine. If you repeatedly knock on my door when I've told you that's my nap time, you're harrassing and disturbing the peace.

Lines get drawn all the time, in every endeavor.

So you say, but inherent in the drawing of that line, anywhere, is the legal authority for one entity to prevent another from engaging in creative activity. Once upon a time it was not uncommon within online communities to believe, as I do, that such a prohibition is morally perilous and has indeed done more to hinder creative expression than to reward or protect it.

> If you come knock on my door to sell me shit, you're fine.

I don't consider that to be fine, either. There is a time and place for sales pitches; my front porch ain't it.

Seldom, if ever, is anybody restrained from "engaging in creative activity." As opposed to making public the results of their purported creativity.

> I don't consider that to be fine, either. There is a time and place for sales pitches; my front porch ain't it.

I don't consider it fine, personally, but I have been writing from a strictly legal standpoint. That line, as some idiots have found to their chagrin, does not allow you to shoot strangers who show up at your door.

Because if the government is going to accept returns electronically instead of through the physical mail, then it should accept them without requiring an intermediary.

Interestingly, it does this for corporations, but not for individuals.

Gee, I wonder why.

Personally, I think that (a) the government needs to have my PII to process my taxes, and that (b) having the government require me to also hand my PII to a third party in order to pay taxes is a big fucking security nightmare.

The site that was killed was the IRS direct file site.

The webform is through the free file alliance, aka Turbotax and friends.

The API requires you to jump through a million hoops. Heaven help you if the reason you want to use the API is because you are behind on your taxes, because that will signal that you are not of good character.

Speaking of being behind on your taxes, you have to use paper for any but the last three years of returns anyway.

The Republicans are trying to strangle the IRS and outsource everything.

The IRS, despite its many shortcomings, consistently tries to help people get their taxes filed.

So when the Republicans were in charge, and the IRS wanted to ensure that people could just fill out their forms, but the Republicans in congress wouldn't directly support filing through the IRS, the IRS came up with a workaround. It was a workaround both for them and for Turbotax et al, because it sort of acted like a pressure relief valve.

The workaround allowed people to file their taxes for free, so the IRS was, well maybe not happy, but certainly mollified. The workaround kinda sucked for the taxpayer experience, so Turbotax was happy. And the workaround was implemented by private companies rather than the US government, so the Republicans were happy.

But you definitely have to hand your data over to a third party to use this workaround -- effectively the same evil (cough, Turbotax, cough) party you were trying to avoid in the first place.

When the democrats were in charge, they effectively torpedoed the workaround with DirectFile, so of course when the Republicans got back in charge, they had to axe that.

By the way, you mentioned an API. Free file fillable forms does not have one. The only one I know of is the one that the tax program vendors use. Yes, it is publicly documented, but to use it you have to jump through a lot of regulatory hoops.

Sure there are. If you want to do weird and wacky stuff, try to do it with an ARM and see how fast you get shut down.

> The improvement is entirely "we don't have to pay ARM"

No, it's "we don't have to beg and grovel, or pay ARM."

Of course, in the more distant past, AMD and Intel sued each other a lot. But there have been a dozen or so x86 market entrants. I think the competition has just been brutal.

So, with either one, you could, of course, do a clean-sheet design and hope you don't get sued.

Since ARM has historically only sold IP, they are incredibly jealous of their monopoly for that ISA. Of course, the flip side of it is that if you have enough money, and you beg and grovel enough, you can probably do what you want with their code.

Except, of course, when you can't. Or rather, maybe you can, but they will try really hard to stop you.

For example, Qualcomm, an architecture licensee who had purchased the rights to basically make whatever the fuck ARM they wanted, purchased a startup named Nuvia that also had an architecture license, and started using Nuvia's designs.

ARM sued, just because. They were shut down in court, but the message is clear. They are very aggressive.

Seriously, who needs that shit? Semiconductor market windows are tight enough as it is, and ARM has always acted like "Nice chip you've got there, buddy; shame if you haven't dotted your i's anc crossed your t's on the licensing."

At least with Intel or AMD, you're probably only looking at patent lawsuits, and you could probably do a decent job on a low end machine with techniques that were known 20 years ago.

You could do the same with ARM, of course, but they will sue you just because, to see if they can make you run out of money.

But there are now several RISC-V IP vendors, and ARM can't possibly shut them all down, and companies can develop IP in-house, so there are lots of different designs already out there.

So, at this point, developing a RISC-V processor provides a certain amount of safety in numbers, kind of like swimming in a school of fish, while developing an ARM compatible processor paints a target on your back.

Developing a low-end x86 processor wouldn't attract any legal attention either, but now that the RISC-V ecosystem is big enough, why bother? Decoding all those instructions might be a lot of extra work for no real market share gain.

Developing a high-end x86 processor would probably attract careful scrutiny of exactly how you managed to get that performance and whether you violated any patents to do that. Again, that the same sort of patent scrutiny would happen with bleeding edge RISC-V, but certainly, a fast x86 processor would be higher on the priority list of the Intel and AMD legal departments.

Because, if you look at the current trajectory of RISC-V micro-architectures: they will be competitive, so current hardware big tech will try hard to shut them down. If they are already at Zen3 performance... I run Zen2 and it's already beyond than enough (I miss AVX512 extensions though, hope we'll get often RVA cache line vector instructions on RISC-V).

Look at qualcomm already buying what seems to be a very good RISC-V microarchitecture, wonder what they will do to it (usually, they let it die slowly forcing their good engineers to work on something else).

The right way(TM) would be for ARM to "drop its ISA" and become a microarchitecture designer able to decode and run RISC-V ISA.

Intel and AMD should too. The world would be basically competing micro-archs all with high compatibility at machine code level.

And it seems nobody has been addressing the elephant in the room: x86 is an horrible ISA for a modern CPU, much more worse than RISC-V/ARM. It is only because AMD/Intel throw tons of money with tons of brains to make that horrible ISA performant AND because they are hogging the production capacity of the best silicon process.

There is zero wonders here.

The first issue is on the purely physical level. The fabs (and integrated companies like Intel) fight this one out, and eye each others' patent stacks and maybe exchange a bit of money. This is not something the average Joe can worry about; nobody has the money to build the fab or engage in the chemical and materials research.

The second issue and implication is on the logic and circuitry level. The average Joe is not going to be able to design and test something really big and performant, but many companies (not just Intel, AMD, and ARM) are capable of this, and again, money might change hands, but (aside from things like China) absolute shutting down of competitors is not really going to happen.

So big players will dominate the highest performance market, but at least there are probably a dozen or so of them, so that will provide some pressure on its own.

Lower performance chips (some of which will be more than performant enough for many niches) will probably proliferate. The profit margin on these chips will be cutthroat, because the average Joe can design them, and then needs to negotiate with, e.g. TSMC, to actually build the damn things.

And a lot of innovation will happen in these lower-level chips as well. Expect many startups to be bought by the bigger players to enhance their own patent portfolios. And expect that their competitive prices will also drive down the cost of the most performant chips a bit.

The performance chip companies will have interesting choices to make. Lower the price to knock out the competition below? Or raise the price? If they raise the price too much, their available market will shrink, and then they'll need to raise the price even more.

There are actually many of those. But Risc-V has become, through effective marketing, the Schelling point for anybody who wants to avoid the x86 and Arm ecosystems, both for the rent-seeking behaviors you mention, and also, in some instances, for security reasons.

And, as others have mentioned, the ISA doesn't really matter. As long as it's agreed upon, then the CPU vendors can optimize on one side, and the compiler writers on the other side.

Sure, Risc-V has its warts, but you can certainly say the same about all the rest.

I find the statement ironic and somewhat amusing (or bemusing – depending on the perspective) for reasons entirely unrelated to CPU's and/or RISC-V.

I keep hearing the phrase «we shall leave that to the vendors» every now and then. Only a few days ago, whilst attending a working-group session on an emerging data exchange standard, precisely the very much same argument was bluntly stated: «We do not particularly care how complex the specification becomes because the vendors will implement it. We shall leave it to them».

The issue is that «the vendors» are not a single mythical intelligence or force possessed of infinite technical wisdom, unlimited, cosmic scale engineering resources and an relentless desire to right the wrongs.

They are businesses. They have narrow commercial objectives, conflicting priorities, disparities in the engineering talent and resourcing and, quite properly, incentives to advance their own products – you are right, to compete with other vendors. Where an opportunity appears to increase market share, lock customers in, differentiate their platforms and products or shift implementation burden elsewhere, one should expect them to notice it. It is not an accusation, it is merely an acknowledgement that vendors tend to behave like vendors.

So with «the vendors will do X», at best, we may hope that vendors will deliver an interpretation of the specification – to a degree, provided that doing so aligns sufficiently well with their commercial interests. An equally plausible outcome is that they will not – or that they will each implement mutually incompatible interpretations whilst proclaiming full compliance.

What you find may or may not match reality. In this instance, I don't believe it does.

> We do not particularly care how complex the specification becomes because the vendors will implement it. We shall leave it to them.

This, of course, is a silly argument. Yet, it is completely orthogonal to the one I was making, and is 180 degrees away from the complaints leveled at Risc-V which are that it is an overly simplistic, nay childish, specification, written in crayon by kindergartners.

> The issue is that «the vendors» are not a single mythical intelligence or force possessed of infinite technical wisdom, unlimited, cosmic scale engineering resources and an relentless desire to right the wrongs.

I find this statement accurate, yet condescending. Who the fuck thinks that they are? Claiming that this is an "issue" with my statement appears to be a reductive argument that I have not thought it through. To be blunt, this statement reveals a hell of a lot more about your ignorance on this issue than mine.

> It is not an accusation, it is merely an acknowledgement that vendors tend to behave like vendors.

And yet, we have seen this play out in x86, with Intel v. AMD, and it worked exceptionally well.

> An equally plausible outcome is that they will not – or that they will each implement mutually incompatible interpretations whilst proclaiming full compliance.

Of course, AMD and Intel were always trying to one-up each other, but that is tempered by the necessity for their improvements to be supported by compilers. By the time an improvement is well-supported, the other side has caught up.

With Risc-V this is even more likely to be the case, because proprietary extensions will simply not be that well supported by major compiler vendors, who have a hard enough time keeping up with the ratified ones.

Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are:

* Taking up valuable compressed instruction space; each compressed codepoint has an opportunity cost of 64k uncompressed ones.

* Limited in which registers they can use (usually x8..x15).

* Often clobber their input operand instead of giving a free move.

Also consider that the frequency data that drove the RVC compression decisions was driven by the lack of architecturally fused instructions like sh*add, so any arguments you derive from that data are circular. An instruction can be a good uarch fusion target because it's compressed, and a good compression target because you didn't fuse it in the architecture.

I think designing for uarch fusion in your ISA is coming at it from the wrong end. Fusion is something uarch designers do to make up for shortcomings in the ISA.

Intel has being fusing `CMP` and `Bcc` since Core 2 and AMD since Zen 1.

This is

- already one instruction in RISC-V

- an *extremely* common pattern, often occurring once every 5 or 6 instructions.

This allows a significant code size reduction in comparison with ARM Aarch64, but unfortunately for RISC-V this advantage is frequently not enough to compensate its other defects, especially when reliable code is desired, i.e. where overflow detection is necessary.

Despite that from this point of view ARM Aarch64 is weaker, that is not an intrinsic problem. Aarch64 has an unused block of encodings inside the block used for branch instructions. I have verified that in the currently unused block it is possible to encode not only compare-and-branch instructions covering all the conditions that exist in the RISC-V ISA, but also additional conditions that are missing in RISC-V, where their absence is a problem, like testing for overflow.

I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64.

Nope. Again, the primary advantage that RISC-V has over Aarch64 is that it is the agreed-upon open specification.

The existing a64 conditional branch instructions use a 19 bit field to hold the offset. Add two registers to compare (10 bits) and 3 bits to choose between EQ, NE, LT, LTU, GE, GEU and you're already at 32 bits before having an "opcode" field to choose "RISC-V style conditional branch".

Of course you could reduce the branch offset size down to RISC-V's ±4k which only needs 11 bits when you only have 4 byte instructions, but that's still a 24 bit chunk of unused opcode space to find.

Oh .. looks like 0b10xx is still completely unused. We could grab maybe 1/4 of it

So could do ...

    [31:28] (4 bits):  0b1000 (Fixed primary opcode .. or 0b1001, 0b1010, 0b1011)
    [27:23] (5 bits):  Rs1
    [22:18] (5 bits):  Rs2
    [17:15] (3 bits):  Cond (EQ, NE, LT, GE, LTU, GEU, + possible 2 more)
    [14:4]  (11 bits): Offset (Signed ±4k PC-relative offset)
    [3:0]   (4 bits):  0b0000 (Fixed minor opcode/extension identifier)

Maybe...

    [31:28] (4 bits): 0b1000 (Fixed primary opcode)
    [27:21] (7 bits): Offset[12:6]
    [20:16] (5 bits): Rm
    [15:13] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, etc)
    [12:10] (3 bits): Offset[5:3]
    [9:5]   (5 bits): Rn
    [4:2]   (3 bits): Offset[2:0]
    [1]     (1 bit):  sf (Size flag: 0 = 32-bit compare, 1 = 64-bit compare)
    [0]     (1 bit):  0b0 (Fixed)

Some ::coff:: would criticise the split up offset field. Not RISC-V fans of course. And this puts sf in a non-standard place.

Some more playing around is needed .. over to you Arm.

Not sure if there's an impact caused by the late addition as opposed to always having them, but considering this is a fairly core thing what a program does, not sure what degree of fragmentation this causes on the level of compilers and hardware.

x86 effectively killed innovation in the SIMD space by making instruction set support so fragmented, that people had to target the decade-old lowest denominator.

But *code size* is a demonstrable fact.

RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23.

Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate.

In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test.

The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.

All the claims of the RISC-V fans that I have seen in the past compared the compressed variant of RISC-V with the uncompressed variants of the other ISAs.

Most other ISAs, like ARM, POWER and MIPS, also have compressed variants and if RISC-V were compared with those, it would lose.

Moreover, if you use safe compilation options with RISC-V, the code size explodes in comparison with any other ISA, because I am not aware of any other ISA introduced after 1974 that lacks hardware overflow detection, which multiplies by 3 or more the number of arithmetic instructions required for any computation.

This is a new claim that I see now, that RISC-V can be more compact than Cortex-M33 (i.e. where both use a compressed encoding), which I find unbelievable, because if I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V and I doubt that the current compilers are so bad that they generate much worse code.

RISC-V is shorter on any code that has a lot of branches and negligible computations, but for anything more complex, with many computations and complex data structures, it loses.

Do you have any specific project in mind that I could use for testing?

I don't understand how the two viewpoints fit together

Well, they don't and they do. Linux runs on everything from an $8 generic IP camera to the world's fastest supercomputers.

RISC-V is attempting to achieve the same feat in hardware, so there will be many implementations at many price points.

As with any of the T-shirts that list 3 things and say "Pick two" it's always difficult to reduce cost, increase speed, and decrease code size.

But...

You can pick two.

So if you don't mind spending the money for things like fancy micro-op caches, you don't care about the compressed decode, and you can still make it run like a bat out of hell with compressed instructions.

Or if you don't mind lower performance, you don't worry about fusing operations, and the pipeline implications aren't so bad, so you can still make something cheap that works with compressed instructions.

It's only when you're trying to pick all 3 (compressed instructions, high instruction throughput, and low cost) that the difficulty of decompressing the instructions becomes problematic.

Or look at it this way. x86 decode is infinitely more complicated than RISC-V decode, and still occupies maybe 2% of the die area.

> I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V

Not if you use the RISC-V ISA properly.