M-Labs/nac3
M-Labs/nac3
8
1
Fork 13
Code Issues 100 Pull Requests 5 Releases Wiki Activity

Implement core_log and rtio_log to ARTIQ #488

Merged
sb10q merged 8 commits from feature/core-rtio-log into master 2024-08-13 15:19:03 +08:00
Conversation 2 Commits 8 Files Changed 13 +30
1 changed files with 30 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 19fd03c515 - Show all commits

30
nac3artiq/src/codegen.rs
View File

@ -724,3 +724,33 @@ pub fn rpc_codegen_callback() -> Arc<GenCall> {
rpc_codegen_callback_fn(ctx, obj, fun, args, generator)
})))
}
/// Returns the `fprintf` format constant for the given [`llvm_int_t`][`IntType`] on a platform with
/// [`llvm_usize`] as its native word size.
///
/// Note that, similar to format constants in `<inttypes.h>`, these constants need to be prepended
/// with `%`.
#[must_use]
fn get_fprintf_format_constant<'ctx>(
llvm_usize: IntType<'ctx>,
llvm_int_t: IntType<'ctx>,
is_unsigned: bool,
) -> String {
debug_assert!(matches!(llvm_usize.get_bit_width(), 8 | 16 | 32 | 64));
let conv_spec = if is_unsigned { 'u' } else { 'd' };
// https://en.cppreference.com/w/c/language/arithmetic_types
sb10q commented 2024-08-12 20:56:10 +08:00
Outdated
Review
Copy Link

I suppose this should make it straightforward now to implement the full print_rpc() with several arguments?

I suppose this should make it straightforward now to implement the full ``print_rpc()`` with several arguments?
derppening commented 2024-08-13 12:01:50 +08:00
Outdated
Review
Copy Link

Not really. This only makes it straightforward to implement print_rpc/core_log/rtio_log with several arguments of the same type, as is required by the current implementation of varargs (Varargs are typechecked against its expected type, e.g. *int32 requires all arguments in the variadic position to be int32).

In order to implement these functions with variadic arguments of different types, we still need a type category which accepts any type (think TypeEnum::TAny), and that needs to be first implemented. The closest equivalent we have is *T (where T is a typevar), but this still requires all arguments to be of the same type T.

Not really. This only makes it straightforward to implement `print_rpc`/`core_log`/`rtio_log` with several arguments *of the same type*, as is required by the current implementation of varargs (Varargs are typechecked against its expected type, e.g. `*int32` requires all arguments in the variadic position to be `int32`). In order to implement these functions with variadic arguments of *different* types, we still need a type category which accepts any type (think `TypeEnum::TAny`), and that needs to be first implemented. The closest equivalent we have is `*T` (where `T` is a typevar), but this still requires all arguments to be of the same type `T`.
sb10q commented 2024-08-13 12:05:30 +08:00
Outdated
Review
Copy Link

with several arguments of the same type, as is required by the current implementation of varargs

So the _log functions currently have the same limitation, correct?

> with several arguments of the same type, as is required by the current implementation of varargs So the _log functions currently have the same limitation, correct?
derppening commented 2024-08-13 12:10:34 +08:00
Outdated
Review
Copy Link

_log functions are currently implemented with a single non-vararg parameter. I think we can merge this first before expanding support to homogeneous varargs?

`_log` functions are currently implemented with a single non-vararg parameter. I think we can merge this first before expanding support to homogeneous varargs?
sb10q commented 2024-08-13 14:35:58 +08:00
Outdated
Review
Copy Link

Yes, just trying to understand where we are.

Yes, just trying to understand where we are.
// Note that NAC3 does **not** support LP32 and LLP64 configurations
match llvm_int_t.get_bit_width() {
8 => format!("hh{conv_spec}"),
16 => format!("h{conv_spec}"),
32 => conv_spec.to_string(),
64 => format!("{}{conv_spec}", if llvm_usize.get_bit_width() == 64 { "l" } else { "ll" }),
_ => todo!(
"Not yet implemented for i{} on {}-bit platform",
llvm_int_t.get_bit_width(),
llvm_usize.get_bit_width()
),
}
}