about summary refs log tree commit diff stats
path: root/subx
Commit message (Collapse)AuthorAgeFilesLines
* 4540Kartik Agaram2018-09-111-2/+2
|
* 4538Kartik Agaram2018-09-075-16/+16
|
* 4537Kartik Agaram2018-09-077-41/+97
| | | | | | | | | | | | | | | Streamline the factorial function; we don't need to save a stack variable into a register before operating on it. All instructions can take a stack variable directly. In the process we found two bugs: a) Opcode f7 was not implemented correctly. It was internally consistent but I'd never validated it against a natively running program. Turns out it encodes multiple instructions, not just 'not'. b) The way we look up imm32 operands was sometimes reading them before disp8/disp32 operands.
* 4535 - support for global variable namesKartik Agaram2018-09-017-77/+203
|
* 4534Kartik Agaram2018-09-011-0/+0
| | | | | | | | | | | | | | | I'd been planning to add segment address computation after all labels were computed, including labels in the data segment (which isn't built yet). But now I realize that won't work, because labels in the data segment will require segment start addresses. We need to deal in absolute addresses rather than relative offsets as with the jump instructions that use code labels. Layer 34 is now broken by this change in a way that isn't obvious right now: it is oblivious to imm32 and disp32 operand tags that are now going to be present in the programs it sees. It's a lucky accident that everything still works, because we're only using segment names right now for the very first (code) segment in a program.
* 4533Kartik Agaram2018-09-012-0/+3
|
* 4532Kartik Agaram2018-09-012-28/+36
| | | | Make segment names a separate transform.
* 4531 - automatically compute segment addressesKartik Agaram2018-09-0114-61/+83
|
* 4530 - create an apps/ directoryKartik Agaram2018-09-0111-205/+217
|
* 4529 - move examples to a sub-directoryKartik Agaram2018-09-0121-12/+11
|
* 4528 - commandline arguments working nativelyKartik Agaram2018-08-313-22/+9
| | | | | | | | | | | | | | Turns out I had totally the wrong idea. The stack at the start of the program doesn't contain 2 words, one for argc and a second for argv that must then be dereferenced to get to its contents (each a pointer to a string). It contains a word for argc, one for argv[0], another for argv[1], and so on. Many thanks to Jeremiah Orians and the #bootstrappable channel on freenode for showing me https://github.com/oriansj/mescc-tools/blob/master/test/test5/exec_enable_amd64.M1 which set me straight. I could just pop the args like that example does, but it seems slightly more elegant, given the current calling convention, to assume the imaginary caller handles the popping.
* 4527 - reading commandline argumentsKartik Agaram2018-08-308-14/+166
| | | | | | | | | | | The new example ex9 doesn't yet work natively. In the process I've emulated the kernel's role in providing args, implemented a couple of instructions acting on 8-bit operands (useful for ASCII string operations), and begun the start of the standard library (ascii_length is the same as strlen). At the level of SubX we're just only going to support ASCII.
* 4526Kartik Agaram2018-08-291-1/+1
| | | | | New levels should be added at the top of list of transforms rather than bottom. See layer 29.
* 4524Kartik Agaram2018-08-204-6/+6
|
* 4523 - Give up on pass-through phasesKartik Agaram2018-08-207-269/+4
| | | | | | | | | | | | | | | | | | | | I'm going to continue using them for now, but I'm fairly certain now that they're just a temporary device to help rapidly-prototype ideas. The reason: there's just too many ways to abuse low-level features, and it ends up taking too much code to disallow things soon after you allow them. New plan: stop trying to write checks, just treat them as temporary conventions for now. Goal is now to just get the core sequence of passes nailed down. Then we'll start reimplementing them from the ground up. First implication of this new plan: ripping out most existing checks. I'm still going to eventually build type checks. But no degenerate checks for code just being too low-level. (This decision is the outcome of a few days of noodling over Forth and https://mastodon.social/@akkartik/100549913519614800.)
* 4522Kartik Agaram2018-08-141-3/+3
| | | | Don't use trace infrastructure if you're just going to immediately exit.
* 4520 - several syscalls for filesKartik Agaram2018-08-134-0/+180
|
* 4519Kartik Agaram2018-08-131-5/+5
|
* 4518Kartik Agaram2018-08-131-3/+24
| | | | Support both signed and unsigned numbers when parsing strings.
* 4517Kartik Agaram2018-08-132-2/+3
| | | | | We want to always print numbers in hex. This should make that a little more comprehensive.
* 4516Kartik Agaram2018-08-133-4/+4
|
* 4515Kartik Agaram2018-08-131-1/+1
| | | | Fix CI.
* 4514 - prefix jump targets with function nameKartik Agaram2018-08-121-2/+2
| | | | | | | | I'd been planning next to automatically namespace jump targets in different functions. But just a check for duplicate labels should suffice, and managing unique names isn't a huge burden. I'm wary of growing the translator too much. All this will eventually need to be self-hosted in SubX.
* 4513 - disallow jumps across functionsKartik Agaram2018-08-122-2/+62
|
* 4512 - divide labels into two categoriesKartik Agaram2018-08-126-16/+101
| | | | | | | | | Targets you can jump to and ones you can call are conceptually disjoint sets. I'm highlighting these in Vim, but it's a pretty complex pattern. Arguably errors shouldn't be highlighted. Only warnings that are easy to be accidentally deployed.
* 4511Kartik Agaram2018-08-121-0/+2
|
* 4510 - check manual examples in CIKartik Agaram2018-08-121-0/+12
|
* 4509Kartik Agaram2018-08-121-5/+5
|
* 4508Kartik Agaram2018-08-121-1/+1
|
* 4507Kartik Agaram2018-08-122-12/+36
| | | | | Side effect: better error messages when the tangler does something unexpected.
* 4506Kartik Agaram2018-08-121-2/+2
|
* 4505 - start warning on jumps without labelsKartik Agaram2018-08-114-10/+111
| | | | | As we climb the ladder of abstraction we'll gradually pull the ladder up behind ourselves.
* 4504Kartik Agaram2018-08-111-5/+22
|
* 4503Kartik Agaram2018-08-111-0/+9
|
* 4502Kartik Agaram2018-08-111-1/+1
|
* 4501Kartik Agaram2018-08-112-2/+4
|
* 4500Kartik Agaram2018-08-091-0/+5
|
* 4499Kartik Agaram2018-08-095-10/+11
| | | | | More tweaks for check passes. Ensure they're never first-class transforms.
* 4498Kartik Agaram2018-08-091-0/+18
|
* 4497Kartik Agaram2018-08-081-0/+14
|
* 4496Kartik Agaram2018-08-081-0/+16
|
* 4495 - nail down a few more error statesKartik Agaram2018-08-082-9/+23
| | | | | It would be confusing to use negative numbers in raw hex. But we'll rely on programmer taste there.
* 4494Kartik Agaram2018-08-081-0/+21
| | | | | | Hacky test. I'm creating a helper to run tests just for this layer. But I won't be able to do this when I want to selectively run just transforms below some level.
* 4493Kartik Agaram2018-08-081-1/+19
|
* 4492Kartik Agaram2018-08-051-0/+9
|
* 4491Kartik Agaram2018-08-051-0/+11
|
* 4490Kartik Agaram2018-08-051-14/+0
|
* 4489Kartik Agaram2018-08-052-1/+3
| | | | | | The current approach to warnings is workable. We'll just never print warnings to the screen in tests. In tests you can do whatever you want. This is simpler than messing with levels of warnings.
* 4488Kartik Agaram2018-08-051-2/+1
|
* 4487Kartik Agaram2018-08-052-1/+6
| | | | | | | | | | | Draft attempt at cleaning up warnings, but this isn't quite right. We still emit warnings for every level-1 scenario, and hiding for each of them seems painful. Even if we do that, level-2 scenarios would want to hide level-3 and over warnings, but *not* level-1 warnings. So we need a cardinal number rather than booleans.