paweld/fpc
1
0
Fork 0
mirror of https://gitlab.com/freepascal.org/fpc/source.git synced 2025-04-23 21:30:12 +02:00
Code Issues Packages Projects Releases Wiki Activity
70,235 Commits 100 Branches 75 Tags 291 MiB
8702fc416b
Commit Graph

70235 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Michaël Van Canneyt
8702fc416b * Do not load font config if it is already loaded 2024-08-09 10:33:05 +02:00
Michaël Van Canneyt
abf04f1086 * Use correct class to construct dictionary in callback helper 2024-08-09 10:24:13 +02:00
Michaël Van Canneyt
258211e038 * Fix wrong raise statement 2024-08-09 09:55:02 +02:00
florian
d4816d12f7 * Risc-V 32 has also a GC variant 2024-08-08 22:58:47 +02:00
Michaël Van Canneyt
594b96e305 * Add CopyToMemory 2024-08-08 17:36:16 +02:00
Michaël Van Canneyt
025ad39ef0 * Do not raise exception 2024-08-08 10:15:45 +02:00
Michaël Van Canneyt
a81eac2483 * Correct dictionary construction 2024-08-08 09:59:40 +02:00
Michaël Van Canneyt
37c32a9eb7 * Explicitly specify path to include files 2024-08-08 09:59:40 +02:00
Michaël Van Canneyt
22c978c33f * Print clickable URL with start location 2024-08-08 09:59:40 +02:00
florian
1ecc880fc8 + cpu type RV64GC 2024-08-07 22:53:10 +02:00
Nikolay Nikolov
af5c2d66c2 * removed TODO comment from WasiThreadSwitch 2024-08-07 18:26:19 +03:00
Nikolay Nikolov
5d058258fc + added some more comments in wasi_thread_start 2024-08-07 18:19:35 +03:00
Nikolay Nikolov
a0e1dce1fd * WebAssembly threads: call fpc_wasm32_init_tls from inline asm code to avoid 
race condition in branchful exceptions mode
 2024-08-07 18:17:38 +03:00
Nikolay Nikolov
fcfce9f2d5 * WebAssembly threads: implement WasiEndThread using exceptions. There's no 
other way to end a thread in WebAssembly, except by ending the thread
  procedure. Therefore, the only way to implement WasiEndThread is to have it
  raise an exception and handle it at the outermost level. This, of course,
  requires one of the WebAssembly exception modes to be turned on, in order for
  this to work.
 2024-08-07 17:58:11 +03:00
Nikolay Nikolov
e03389c6a8 * WebAssembly threads: destroy the event and mutex in WasiBeginThread in case wasi_thread_spawn fails 2024-08-07 17:06:03 +03:00
Nikolay Nikolov
77d592221a * WebAssembly threads: use New and Dispose instead of GetMem/FreeMem for allocating/freeing TWasmThread 2024-08-07 16:46:13 +03:00
Nikolay Nikolov
f23cc9ec6d * WebAssembly threads: free the stack block and TLS block in case wasi_thread_spawn fails 2024-08-07 16:44:44 +03:00
florian
e6ba09aedd + Risc-V 64: tcpuparamanager.get_saved_registers_int and tcpuparamanager.get_saved_registers_fpu 2024-08-06 22:56:35 +02:00
Michaël Van Canneyt
d0b03c9c71 * Correct callback handler for object tree 2024-08-06 09:32:00 +02:00
Michaël Van Canneyt
25af7a4281 * Export get_object_tree 2024-08-06 09:32:00 +02:00
Michaël Van Canneyt
45ec51dc1f * Install error handler to examine exceptions during callback 2024-08-06 09:00:11 +02:00
Nikolay Nikolov
9e0b2869a3 * WebAssembly threads: disable stack checking for the FPCWasmThreadStartPascal procedure 2024-08-06 07:07:41 +03:00
Nikolay Nikolov
9d771396ff + WebAssembly threads: init StackBottom (used for stack checking) more precisely 
when starting a new thread. Precision is not that important for the stack
  checking itself, because it uses a stack margin of 16kb, so the previous
  value, set by InitThread is good enough, however it's easy to do it precisely,
  since we allocate the stack and pass a pointer to it in TWasmThread, so why
  not?
 2024-08-06 07:01:28 +03:00
Nikolay Nikolov
da59711442 * WebAssembly threads: pass the stack size to InitThread when starting a new thread 2024-08-06 06:40:33 +03:00
Nikolay Nikolov
8bbb28ace8 + WASI: enable the generic stack checking 2024-08-06 05:00:14 +03:00
Nikolay Nikolov
68f4191119 + WASI: set StackBottom on startup 2024-08-06 04:02:15 +03:00
Nikolay Nikolov
60bb6c19d9 + WASI: set StackLength on startup 2024-08-06 03:55:52 +03:00
Nikolay Nikolov
b340994e1b * proper implementation for the function Sptr (which returns the stack pointer) for WebAssembly 2024-08-06 03:16:41 +03:00
florian
23dec631f5 + Risc-V: apply OptPass1OP to more operations 2024-08-05 22:37:59 +02:00
florian
3e6cd16bb5 + Risc-V 32: tcpuparamanager.get_saved_registers_int 2024-08-05 22:37:18 +02:00
Nikolay Nikolov
3c027b0ba0 * WebAssembly threads: use the stack size, specified for the main thread (via 
the $M directive, or the '-Cs' compiler option) as the default stack size for
  other spawned threads
 2024-08-05 01:59:13 +03:00
Nikolay Nikolov
a417b0db9b * WebAssembly threads: simplified (optimized) the implementation of 
TWasmRTLEvent, so it doesn't use a Mutex. Use atomic operations instead.
 2024-08-05 00:31:27 +03:00
florian
4afb07cc5e + Risc-V 32: tcpuparamanager.get_saved_registers_fpu 2024-08-04 23:03:44 +02:00
Nikolay Nikolov
74a4550ff0 * WebAssembly threads: fix TThread.WaitFor (use -1 instead of 0 to signal infinite timeout) 2024-08-04 21:09:18 +03:00
Nikolay Nikolov
6be3a42a2f * WebAssembly: optimized SysOSAlloc to use memory area left at the end of the 
page (64kb). This reduces memory use, when SysOSAlloc is called with sizes,
  smaller than 64kb.
 2024-08-04 18:04:10 +03:00
Michaël Van Canneyt
a0c11becde * Small fix in saveobject 2024-08-04 12:02:05 +02:00
Nikolay Nikolov
801f902efe * WebAssembly threads: fix threadvars with the new WASI-threads implementation 2024-08-04 05:50:06 +03:00
Nikolay Nikolov
aaf536ae10 * WebAssembly: allow specifying the initial and max memory size via the $M 
directive
 2024-08-04 04:11:10 +03:00
Nikolay Nikolov
7681c192db * WebAssembly threads: protect SysOSAlloc against race conditions via a critical section 2024-08-04 03:15:31 +03:00
Nikolay Nikolov
9cf31e2bb3 + show a message and automatically switch to external linking if WebAssembly multithreading is enabled 2024-08-04 02:55:34 +03:00
Nikolay Nikolov
31bb06ac87 + WebAssembly threads: initial implementation of the WASI threads proposal: 
https://github.com/WebAssembly/wasi-threads

  Note that the WASI folk have already declared this proposal 'obsolete' and
  only intended to be used for engines that support WASI v0.1. On the other
  hand, the WASI v0.2 threads proposal is an early draft and not implemented
  anywhere, so we have no choice, but to stay with v0.1 at this time, or give up
  on multithreading for who knows how long it would take for the v0.2 spec to be
  completed.

  Regarding the WASI v0.1 engines that implement WASI threads correctly and can
  be used with Free Pascal, I've discovered only one that works:

    https://github.com/bytecodealliance/wasm-micro-runtime/tree/main

  Wasmtime claims to support multithreading since version 15, however it doesn't
  seem to work. I tested all versions until the 23.0.1, and none of them works.

  Caveat: using the internal linker is not yet supported with WebAssembly and
  multithreading. Please use the external linker (the -Xe option), if you want
  to give this new feature a try.
 2024-08-04 02:24:20 +03:00
Nikolay Nikolov
bb93b918a5 * WebAssembly threads: don't check for GetThreadState(MyThread)<>tsRunning in 
LockMutexTimeoutWait and LockMutexTimeoutNoWait
 2024-08-04 01:56:25 +03:00
Nikolay Nikolov
694341aa78 * WebAssembly threads: fixed bug in LockMutexTimeoutNoWait, caused by the use of 
Result instead of Res. This stupid bug broke WebAssembly critical sections,
  causing random spurious hangs and it took me quite a lot of time to find it!
 2024-08-04 00:37:16 +03:00
Nikolay Nikolov
c2fcb1a833 * WebAssembly threads: reformat code in LockMutexTimeoutNoWait for better 
readability by removing begin..end blocks and replacing it with an 'else if'
  chain. No functional changes.
 2024-08-04 00:33:44 +03:00
florian
cc2406ad74 * factor out TRVCpuAsmOptimizer.OptPass1Add 2024-08-03 21:55:41 +02:00
Nikolay Nikolov
e612401562 * WebAssembly threads: also access TRTLCriticalSection.Owner using atomic loads and stores 2024-08-03 02:58:32 +03:00
Nikolay Nikolov
6a1eb520e9 * WebAssembly threads: use atomic loads and stores for accessing TRTLCriticalSection.Locked 2024-08-03 02:51:27 +03:00
Nikolay Nikolov
41ead20bfb * WebAssembly threads: fixed race condition LockMutex in the check where Locked 
is 1, but Owner still holds the current thread id, even though another thread
  has just acquired a lock, but still haven't updated the owner thread ID. We
  avoid this problem by setting Owner to nil before unlocking the mutex. And in
  InitMutex/DoneMutex, we store the creator thread ID in a different field -
  Creator, instead of Owner.
 2024-08-03 02:34:05 +03:00
Nikolay Nikolov
692bd62359 * WebAssembly threads: bug fixes in LockMutexTimeoutWait 2024-08-03 01:29:04 +03:00
florian
8708144c50 + RiscV: AndiAndi2Andi 2024-08-02 22:15:37 +02:00