Created
December 30, 2020 08:13
-
-
Save sozysozbot/b973b6f592eb3e990f904f56584a43a7 to your computer and use it in GitHub Desktop.
A somewhat formal spec for https://github.com/osdev-jp/osdev-jp.github.io/wiki/OpeLa-Language-Specification/af444370e8fa0b4681a980682127f2d79f55753f
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(** | |
以下、日本標準時 (UTC+9:00) においては西暦2020年12月30日に行われた会話である | |
hsjoihs 16:29 | |
おっ。とりあえず私はOpeLaの構文論を形式化しようとしています | |
uchan_nos 16:29 | |
そんなことを!?w | |
hsjoihs 16:30 | |
とりあえず、グローバルな定義については、「プログラム例:割り込み」に書いてある、実装したいのであろうと推察される機能全部カバーするEBNFが書けました | |
uchan_nos 16:32 | |
言語仕様考えてる人もEBNF考えてないのに… | |
hsjoihs 16:32 | |
仕様には書いてませんけど、マスクフィールドって構造体型や配列型への適用は不可ですよね? | |
あーでも整数型がtypedefされてそれがマスクされる可能性はあるから、構文論としては許すべきかもな | |
hsjoihs 16:36 | |
んーー、でもマスクフィールドとかいう低レイヤな操作をする上で、ビット幅が typedef されているなんて状況を許したいだろうか?うーん難しい | |
uchan_nos 16:37 | |
えーと(ここでOpeLa言語仕様を見直す | |
マスクフィールドは整数型に適用することだけ考えてましたね | |
uchan_nos 16:39 | |
確かに構文としてはtypedef nameに対するマスクフィールドを許可しておきたくなる…のか? | |
hsjoihs 16:39 | |
`Addr address64[63:12]` ってフィールドに書けるんですけど、例えばこれ `Addr address[63:12]` みたいなのを許すことにすると、ネイティブ幅に依存して意味が通ったり通らなかったりしちゃうじゃないですか | |
uchan_nos 16:40 | |
ですね。 | |
hsjoihs 16:41 | |
どうしても32bit幅でも64bit幅でも下位12ビットをマスクしたい場合のために `Addr address[:12]` みたいに書けるようにしちゃうという手もあるんですけど、そんなことするぐらいだったら、ビット幅がソースコードに書いてあるたぐいの整数型にのみ適用、としたほうがいいのかも?って思ってました | |
uchan_nos 16:41 | |
[63:12]はあくまでマスクだから、addressが32ビット幅の環境では単に上位32ビットが無視され、[31:12]と指定したとみなす、というのも妥当性があるかと考えました。 | |
uchan_nos 16:43 | |
確かに、マスク機能はビット幅固定の組み込み整数型にのみ適用可能、というのも一理ある。 | |
hsjoihs 16:44 | |
いずれにせよ、ユーザーが好き勝手に typedef した型名にマスクを付けるのは不許可でいいんじゃないかなぁ、みたいなことを思ってました | |
uchan_nos 16:47 | |
そんな気がします | |
***) | |
(************************************ | |
* Chapter 1: Top-Level Definitions * | |
************************************) | |
program = { top_level_definition }; | |
top_level_definition = type_definition | |
| global_var_definition | |
| func_or_isr_definition | |
; | |
global_var_definition = "var", "(", { | |
identifier, type_name, ";" | |
} ")"; | |
type_definition = "type", identifier, type_name, ";"; | |
intN = ? "int" followed by a nonnegative integer, without any intervening spaces ?; | |
uintN = ? "uint" followed by a nonnegative integer, without any intervening spaces ?; | |
addressN = ? "address" followed by a nonnegative integer, without any intervening spaces ?; | |
nonnegative_integer = ? I wonder if leading zeros are allowed ?; | |
identifier = ? I wonder which identifiers are reserved ?; | |
type_name = builtin_type_name | |
| "struct", "{", { field_name, field_type_name, ";" } "}" | |
| type_name, "[", nonnegative_integer, "]" | |
| "*", type_name | |
| "Atomic", "<", type_name, ">", | |
; | |
builtin_type_name = "int" | "uint" | "byte" | "address" | |
| intN | uintN | addressN ; | |
field_type_name = type_name | |
| builtin_type_name, "[", nonnegative_integer, ":", nonnegative_integer, "]" | |
; (* I suppose the mask field exists only for the builtin types *) | |
field_name = identifier | |
| identifier, "[", nonnegative_integer, "]" | |
; | |
func_or_isr_definition = func_or_isr, identifier, "(", arg_list, ")", "{", { | |
local_stmt | |
}, "}"; | |
(* local_stmt will be defined in Chapter 2 *) | |
arg_list = "" | |
| arg_name_and_type, { ",", arg_name_and_type } | |
; | |
arg_name_and_type = identifier, type_name; | |
func_or_isr = "func" | "isr"; | |
(************************* | |
* Chapter 2: Statements * | |
*************************) | |
local_stmt = expr_stmt | local_def; | |
expr_stmt = ? todo ?; | |
local_def = ? todo ?; |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment