cinera_handmade.network/pervognsen/bitwise/bitwise/bitwise027_1.hmml

39 lines
4.0 KiB
Plaintext
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

[video member=pervognsen stream_platform=twitch project=bitwise title="Static Assembler, Part 2" vod_platform=youtube id=t6diq8J9W0E annotator=Miblo]
[0:08][Recap and set the stage for the day continuing with the static assembler][:asm]
[0:45][Review off-stream work on the static assembler, mentioning differences between C and Ion][:language :research]
[2:07][Magic cookie in the header of a stretchy buffer][:memory :research]
[6:24][Continue to review the introduction of the :memory arena and interning][:parsing :research]
[8:42][Review fixes in the type resolver, including support for null-pointer evaluation in ternary expressions, and separating the equality and relational operators[ref
author=ANSI
title="ISO/IEC 9899: Information technology Programming languages C"
url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf]][:language :parsing :research]
[13:31][Highlight the concision of Ion's idiom declaring a variable as an address of a compound literal][:language :speech]
[16:32][Start to enable the assembler's lexer to support the interned TOKEN_NAME, similar to Ion's][:parsing]
[17:54][Enable Ion's compiler to support ranges denoted by "..." for use in switch cases][:"code generation" :language :parsing]
[26:40][Introduce get_resolved_val() and set_resolved_val() for "..." range resolution][:"code generation" :language :parsing]
[35:27][Step in to set_resolved_val() to see what it produces][:run]
[35:57][Postpone "..." range support for now, and resume work on the assembler's lexer, supporting the interned TOKEN_NAME][:"code generation" :language :parsing]
[40:32][:Run it to see that it correctly interned our strings][:"code generation" :language :parsing]
[41:15][@elavid][I thought your map handled zero values fine, but zero keys were the issue. Also, your memcpy lines will cause an overflow if Val and uint64 are actually different sizes on some platform. You were doing something like memcpy(&u64, &val, sizeof(Val));][:memory]
[41:26][@elavid][Yeah, back to my first comment, I'm looking at map_put and map_get and I don't think you're using 0 as a sentinel value for values, only keys, so I don't understand assert(val)]
[42:17][Fix map_put_uint64() to return if(!val)]
[43:32][@elavid][Okay, I see. You could also have a fancier map_get function that lets you tell if a value was found or not]
[43:42][Make resolve_stmt() convert "..." range operands to type_ullong, and get_resolved_val() catch buffer overflows][:memory :parsing]
[45:26][Enable gen_stmt() to emit all the cases within a given "..." range][:"code generation"]
[49:45][Use our new "..." syntax in the assembler][:parsing]
[50:14][:Run it to see that the "..." range stuff work, and test the interning on strings that only differ by case][:"code generation" :language :parsing]
[51:16][Make the resolver only allow ranges from low to high][:language :parsing]
[54:20][Enable the lexer to handle comments][:parsing]
[57:12][:Run it to see that both the division token and comments are interned correctly][:parsing]
[57:21][Review the addition of goto label support in Ion][:language :research]
[59:38][Make the assembler's next_token() handle \\n separately from the other whitespace characters][:asm :parsing]
[1:01:54][:Run it to see our parsed newlines][:parsing]
[1:02:17][A few words on supporting inclusive "..." case ranges only, and not exclusive ranges][:language :speech]
[1:03:11][Spec out our line-oriented syntax for the static assembler][:asm :parsing :speech]
[1:07:56][Adapt the token and keyword matching code from lex.c to Ion][:parsing]
[1:17:48][Introduce init_parser() and start on xreg :parsing][:asm]
[1:22:04][@elavid][If you're trying to map the interned string "x3" to the integer 3, you could store that in the interned string header. Or maybe "x3" should be a token recognized by the lexer, and you get the register number by masking off some bits][:parsing]
[1:22:47][Introduce the notion of KeywordData to treat registers, e.g. xreg, as keywords, stored with their associated register number][:asm :parsing]
[1:33:11][Cut off the stream here][:speech]
[/video]