On 2024-12-05 02:26AM, Karurochari wrote:
>> It would involve a lot more than that, since wasm doesn't allow 
>>arbitrary control flow graphs.
>May I ask you to elaborate a  bit more on this? Or, would you have any 
>references to read and better understand what you mean by that?
>Do you see WASM intrinsically incompatible as a target with the 
>premises and/or the current architecture of QBE?
This link has good overview of the limitations of WebAssembly's control 
flow: 
http://troubles.md/posts/why-do-we-need-the-relooper-algorithm-again/

I can't find the link now but there was some forum or mailing list 
thread where LLVM devs said that supporting WASM was "500x more 
difficult than any other architecture" without a shred of hyperbole.

On 2024-12-29 04:50PM, Quentin Carbonneaux wrote:
>I am currently spending all my qbe time integrating optimizations
>by Roland. When that is done, I'd be keen on providing a simple
>PoC with holes for you to plug.
Oh, really!  I'd appreciate it, but I don't want to saddle you with 
stuff that you probably wouldn't have been doing otherwise...

>...an 'm' type would have unspecified size, making it impossible to use 
>it in a portable fashion. LLVM has pointer types, but this is a false 
>convenience (you have to know their size since the bulk of the abi is 
>on you to implement).
Ah

>As a high level suggestion, I'd advise you to get something basic

Hey,

I guess I should say up front, an ARM32 backend materializing from me is 
looking less and less likely by the day lol.  I'd poked at the QBE code 
before so I thought I could muddle through since I had the gist of what 
most of the code does, but it turns out it is extremely difficult to 
figure out how the code all fits together and *specifically* what many 
functions do.  And I can't easily just cargo cult from an existing 
backend since 32-bit requires a number of fundamental changes. Still 
persevering for the moment though.

Some things that slipped my mind in my first message:
1. Many/most ARM32 processors don't have floating-point support, I don't 
know if we want to handle that somehow or just wait for the assembler

Hi everyone,

I'm interested in attemping to implement ARM32 as a target.  While I 
have poked at the codebase a bit, no guarantees I could get it done.  
Although if I do get it implemented then I'm willing to commit to 
maintaining it as well, if necessary.

The main problem is, while 32-bit architectures in QBE are solved in 
theory ("just use `w` instead of `l` for pointers"), it seems to be to 
not really be solved in practice.  It'd be pretty disappointing to get 
the backend implemented and working, but then not be able to use it for 
anything because no frontend implements the de facto incompatible 32-bit 
IR.  Seems like I'd have to convince every frontend to do potentially 
quite a bit of work---or attempt to do it all myself---in order to

Hi!

Thanks so much for the contributions!  Both patches are now applied,
although I took the liberty of modifying them to remove the sweeping
whitespace changes and to clean up some stuff.

First commit: https://git.sr.ht/~nytpu/tlsada/commit/0a63fe01c9ee34495ef9689b0b71a774dd71fc56
- Removed unrelated whitespace changes
- Reworded commit message because I'm very particular about them
- Forced handshakes for Client_Contexts as well as Server_Contexts, for
  similar reasons
- Factored out duplicate code in exception messages

Second commit: https://git.sr.ht/~nytpu/tlsada/commit/134db3791ae3e412d0d4be7ae30b129c5b11d850

Fixed in e688c31 (https://git.sr.ht/~nytpu/commons-downloader/commit/e688c306c53fc617a9648b606f6dc9ea2bacf9ac)

Thanks!

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com

Hi!

On 2022-09-29 01:39PM, Wyatt Avery wrote:
> This project is a huge time saver for me. Simple and effective. So
> thanks to any and all who have worked on it thus far.
Thanks!

> In my use, there is a lot of metadata that's been added to Wikimedia
> Commons that is not embedded within the file, such as date, credit,
> notes, source, and rights (permission).
> 
> When scraping a collection of images it would be invaluable to have
> recorded that information as it came in.
> 

Thanks!

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com

Thanks!

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com

I've been meaning to update it myself for some time but knowing how
personal projects go it probably would've been far into the future, so
this is much appreciated!  Thanks so much!

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-external-key alex@nytpu.com