On: raising the semantic level of a program
dwight
dkelvey at hotmail.com
Sun Jun 28 21:32:14 CDT 2020
For the various flow control works, Forth generally teaches you to not spread flow control across multiple pages. Unless you are really trying to reach for every last clock cycle, it makes sense to factor even assembly code. It makes understanding the code easier and allows one to think about what is happening in the code.
Of course, good choices of names make sense. One can even make a page long macro to paste in-line a block of code for a zero cycle cost factoring.
Factoring is the key to such things. A page of straight assembly is a bad idea in the first place.
I don't see creating labels spread across several pages any better then doing good factoring.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of ben via cctalk <cctalk at classiccmp.org>
Sent: Sunday, June 28, 2020 5:32 PM
To: cctalk at classiccmp.org <cctalk at classiccmp.org>
Subject: Re: On: raising the semantic level of a program
On 6/28/2020 5:20 PM, Peter Corlett via cctalk wrote:
> On Sun, Jun 28, 2020 at 01:32:02PM -0700, Chuck Guzis via cctalk wrote:
> [...]
>> Why is byte-granularity in addressing a necessity?
>
> Because C's strings are broken by design and require one to be able to form a
> pointer to individual characters.
>
Just what is a NON broken string design?
>> It's only an issue if you have instructions that operate directly on byte
>> quantities in memory.
>
> One wheeze is to just declare that bytes are the same size as a machine word. C
> doesn't require char to be exactly 8 bits, but merely at least 8 bits. However,
> a lot of C code will break if char, short, int and long aren't exactly the same
> size as they are on x86. Mind you, a lot of it is still broken even if they
> are...
DISC I/O seems to have stage packed formats of bytes shorts and longs
all packed a character array. Directory structures or inodes come to mind.
The x86 is broken period.
'int' size depends on the compiler making porting programs interesting,
as well as macro processor and make files.
Ben.
More information about the cctalk
mailing list