Packages Demo & RISC-V Intro
?
?

Keyboard Navigation

Global Keys

[, < / ], > Jump to previous / next episode
W, K, P / S, J, N Jump to previous / next marker
t / T Toggle theatre / SUPERtheatre mode
V Revert filter to original state Y Select link (requires manual Ctrl-c)

Menu toggling

q Quotes r References f Filter y Link c Credits

In-Menu Movement

a
w
s
d
h j k l


Quotes and References Menus

Enter Jump to timecode

Quotes, References and Credits Menus

o Open URL (in new tab)

Filter Menu

x, Space Toggle category and focus next
X, ShiftSpace Toggle category and focus previous
v Invert topics / media as per focus

Filter and Link Menus

z Toggle filter / linking mode

Credits Menu

Enter Open URL (in new tab)
0:09Recap and set the stage for the day
0:09Recap and set the stage for the day
0:09Recap and set the stage for the day
3:39Packages: 3 Parts
3:39Packages: 3 Parts
3:39Packages: 3 Parts
6:36Demo packages, as used in test1.ion
6:36Demo packages, as used in test1.ion
6:36Demo packages, as used in test1.ion
10:47Explain the idempotent nature of packages, and the ability to import the same file (e.g. libc) multiple times
📖
10:47Explain the idempotent nature of packages, and the ability to import the same file (e.g. libc) multiple times
📖
10:47Explain the idempotent nature of packages, and the ability to import the same file (e.g. libc) multiple times
📖
12:04Bulk imports
12:04Bulk imports
12:04Bulk imports
15:09Run ion to demo use of the IONHOME environment variable
🏃
15:09Run ion to demo use of the IONHOME environment variable
🏃
15:09Run ion to demo use of the IONHOME environment variable
🏃
19:06Explain the change to noir to denote foreign C files
19:06Explain the change to noir to denote foreign C files
19:06Explain the change to noir to denote foreign C files
20:30Tree shaking1 and its influence on package processing
📖
20:30Tree shaking1 and its influence on package processing
📖
20:30Tree shaking1 and its influence on package processing
📖
28:22Demo lazy code generation by introducing an invalid bogus_func()
28:22Demo lazy code generation by introducing an invalid bogus_func()
28:22Demo lazy code generation by introducing an invalid bogus_func()
34:09Review the package parsing code, including the notion of the current_package
📖
34:09Review the package parsing code, including the notion of the current_package
📖
34:09Review the package parsing code, including the notion of the current_package
📖
38:48Explain the idempotency of sym_global_put(), and optional names for symbols
📖
38:48Explain the idempotency of sym_global_put(), and optional names for symbols
📖
38:48Explain the idempotency of sym_global_put(), and optional names for symbols
📖
45:49Note that resolve_package_syms() only resolves symbols from the home package, unless you import using an explicit name
📖
45:49Note that resolve_package_syms() only resolves symbols from the home package, unless you import using an explicit name
📖
45:49Note that resolve_package_syms() only resolves symbols from the home package, unless you import using an explicit name
📖
47:42Review changes to the generator to handle packages, including get_gen_name_or_default()
📖
47:42Review changes to the generator to handle packages, including get_gen_name_or_default()
📖
47:42Review changes to the generator to handle packages, including get_gen_name_or_default()
📖
52:15Emphasise that this all works on gcc and msys2 on Windows, and gcc on Linux, and has been reported as working on Macintosh
52:15Emphasise that this all works on gcc and msys2 on Windows, and gcc on Linux, and has been reported as working on Macintosh
52:15Emphasise that this all works on gcc and msys2 on Windows, and gcc on Linux, and has been reported as working on Macintosh
53:17Q&A
53:17Q&A
53:17Q&A
53:56printf_armin So it searches in IONPATH for the file, but what happens when there are two files with equal names in the path?
🗪
53:56printf_armin So it searches in IONPATH for the file, but what happens when there are two files with equal names in the path?
🗪
53:56printf_armin So it searches in IONPATH for the file, but what happens when there are two files with equal names in the path?
🗪
55:12Set up to transition to RISC-V
55:12Set up to transition to RISC-V
55:12Set up to transition to RISC-V
56:44Introduce RISC-V2 with mentions of 'The Case for the Reduced Instruction Set Computer'3 and John Cocke4
56:44Introduce RISC-V2 with mentions of 'The Case for the Reduced Instruction Set Computer'3 and John Cocke4
56:44Introduce RISC-V2 with mentions of 'The Case for the Reduced Instruction Set Computer'3 and John Cocke4
1:01:01Note that RISC-V is a tiered architecture5
1:01:01Note that RISC-V is a tiered architecture5
1:01:01Note that RISC-V is a tiered architecture5
1:07:31Recommend reading Chapter 2.2 Base Instruction Formats6
1:07:31Recommend reading Chapter 2.2 Base Instruction Formats6
1:07:31Recommend reading Chapter 2.2 Base Instruction Formats6
1:11:03Consider the major distinguishing feature of RISC-V to be its focus on load-store architecture7 as opposed to x86
1:11:03Consider the major distinguishing feature of RISC-V to be its focus on load-store architecture7 as opposed to x86
1:11:03Consider the major distinguishing feature of RISC-V to be its focus on load-store architecture7 as opposed to x86
1:18:30Plan for the coming weeks of working with RISC-V and beyond, with reasons why we'll be emulating rather than working on real hardware
1:18:30Plan for the coming weeks of working with RISC-V and beyond, with reasons why we'll be emulating rather than working on real hardware
1:18:30Plan for the coming weeks of working with RISC-V and beyond, with reasons why we'll be emulating rather than working on real hardware
1:26:46Q&A
1:26:46Q&A
1:26:46Q&A
1:27:16xanatos387 Will RISC-V in FPGA be limited to 32-bit due to gate count limitations, or is it plausible to do 64-bit?
🗪
1:27:16xanatos387 Will RISC-V in FPGA be limited to 32-bit due to gate count limitations, or is it plausible to do 64-bit?
🗪
1:27:16xanatos387 Will RISC-V in FPGA be limited to 32-bit due to gate count limitations, or is it plausible to do 64-bit?
🗪
1:30:10sci4me Assembler first probably?
🗪
1:30:10sci4me Assembler first probably?
🗪
1:30:10sci4me Assembler first probably?
🗪
1:30:29Sketch out the style of emulator we expect to build
1:30:29Sketch out the style of emulator we expect to build
1:30:29Sketch out the style of emulator we expect to build
1:37:42xanatos387 pervognsen: I understand the compile-to-C backend is never going away, but just hypothetically, if that wasn't a constraint, what would you change / add about Ion while still staying in the same general design space?
🗪
1:37:42xanatos387 pervognsen: I understand the compile-to-C backend is never going away, but just hypothetically, if that wasn't a constraint, what would you change / add about Ion while still staying in the same general design space?
🗪
1:37:42xanatos387 pervognsen: I understand the compile-to-C backend is never going away, but just hypothetically, if that wasn't a constraint, what would you change / add about Ion while still staying in the same general design space?
🗪
1:40:33Wrap it up with a reminder to read Chapter 2.2 Base Instruction Formats8
1:40:33Wrap it up with a reminder to read Chapter 2.2 Base Instruction Formats8
1:40:33Wrap it up with a reminder to read Chapter 2.2 Base Instruction Formats8