@matthey

Quote:

Standard and simple endianness conversion functions would probably suffice in most cases.

Endianness convention, requires you make the convention on loading and saving, but it should be unnecessary, the powerpc has reverse endianness instructions it can handle little endian data, if know it was little endian, so no need to do any convention, the compiler could have been able to handle this.

As for the swap routine you suggested, has problem if put into your code with also checking if have endianness first, you can swap data into wrong endianness, when you have CPU that support that endianness.

The problem is with porting programs, from different CPU types; not clearly knowing what is your trying to do is mistake in the design of C language.

Last edited by NutsAboutAmiga on 22-Dec-2018 at 01:03 PM.
Last edited by NutsAboutAmiga on 22-Dec-2018 at 01:00 PM.
Last edited by NutsAboutAmiga on 22-Dec-2018 at 12:59 PM.
Last edited by NutsAboutAmiga on 22-Dec-2018 at 12:58 PM.
Last edited by NutsAboutAmiga on 22-Dec-2018 at 12:57 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

NutsAboutAmiga wrote: Endianness convention, requires you make the convention on loading and saving, but it should be unnecessary, the powerpc has reverse endianness instructions it can handle little endian data, if know it was little endian, so no need to do any convention, the compiler could have been able to handle this.

PPC endian conversion instructions are load/store instructions. This makes it more difficult for compilers to do bswapX() conversions but GCC is sometimes able to use load/store conversion instructions when __builtin_bswapX() functions are used on non-pointer data. This does require more advanced compiler support. Some CPU ISAs have instructions which convert data after the load/store instruction. This is simpler to implement with a bswapX() function as the function directly translates to an instruction. PPC also supports MMU pages in LE format where all data accesses are transparently converted but this is extremely difficult to support in compilers.

Quote:

As for the swap routine you suggested, has problem if put into your code with also checking if have endianness first, you can swap data into wrong endianness, when you have CPU that support that endianness. The problem is with porting programs, from different CPU types; not clearly knowing what is your trying to do is mistake in the design of C language.

Portable code does have to determine the endian format of the machine it is operating on. This often requires conditional code and could be avoided by marking the endianess of data. New endian specific datatypes are one way to do that but introduce complexity and longer datatype names as well. Are C programmers going to lose interest when their datatype should be uint_least64le_t? How many C programmers are making full and proper use of the new and more complex C99 datatypes? A trial implementation of such a system would be interesting but I would be in no hurry to make it canon C. Maybe it would work out nicely and programmers could remember and make good use of the new functionality.

Last edited by matthey on 22-Dec-2018 at 03:29 PM.

@everyone

Well, I see that I've stirred up a bit of a hornet's next--

But things have gone way astray from my original intents:

1: Find, and fix, any other bugs in HSB2 or MB3--since the one I located (uh, like the French 'located 'the Germans in 1940?) isn't in HSP, comparing the two ought to give a quick diagnosis--Does the compiler call the wrong routine, or is the routine itself in error? Either case, since we have working code, should make for a fairly simple quick fix--but don't look at me, I can't even get the @#$%^&*! debugger to work!

2: What improvements to it would youse guys like to see in the next version? I may post my HBASIC2 "Framework.BAS" on Aminet someday; I'd like to see most of it implemented as part of the program.

3: Portability: So I'm thinking we compile straight to C code--then you just add another stage to make, which the editor executes? Remember, I'm lazy, one of the things I like about BASIC is that the machine does most of the drudge work--I've coded 100 error-free lines of code in a 6-hour day, and it took almost 1000 lines of C code to do the same thing--and he had a good reputation as a coder!

Somebody mentioned AmiBlitz--fine, but I've got well over a gig of legacy code, some going back to M$BASIC 4.x on CP/M (one was originally written in FOCAL, on a PDP-8 ), so....

Anyway, I don't care if the hardware is middle-endian, I just want my code to run!

Last edited by pgf_666 on 03-Jan-2019 at 07:42 PM.

@pgf_666
Early Amiga Basics:
ABasic
AmigaBasic
A/C Basic
GFA Basic

Mid time period Amiga Basics:
Hisoft Basic
Maxon Basic
BlitzBasic

Late Amiga Basics:
PureBasic
TrueBasic
AmiBlitz

I don't know why you are so focused on Hisoft Basic and Maxon Basic. They were popular because of their cheap price and post C= Amiga support. BlitzBasic, TrueBasic and PureBasic were more advanced and are developed today but *not* the Amiga versions because the Amiga is considered to be dead. You don't get support for a dead platform. You get old buggy versions of software and source code if you are lucky. Here is an old version of PureBasic with source code.

https://www.purebasic.com/download.php

TrueBasic doesn't even have their Amiga version online anymore unlike the legacy AtariST version (Is the Amiga more divided and dead than the AtariST?). At the same time, they have a poll for the next platform to support including Android, iOS, and Mac OS X.

AmiBlitz, as a further development of the dead open sourced Amiga version of BlitzBasic, is probably the best chance for a modern Amiga basic but there hasn't been a change to the source in 3 years. Wikiwand states the following about BlitzBasic.

"The first iteration of the Blitz language was created for the Amiga platform and published by the Australian firm Memory and Storage Technology. Returning to New Zealand, Blitz BASIC 2 was published several years later by Acid Software (a local Amiga game publisher). Since then, Blitz compilers have been released on several platforms. Following the demise of the Amiga as a commercially viable platform, the Blitz BASIC 2 source code was released to the Amiga community. Development continues to this day under the name AmiBlitz."

http://www.wikiwand.com/en/Blitz_BASIC

The Amiga platform was much loved as history and open sourcing of Amiga versions of developed products shows but it is *not* a "commercially viable platform". Tiny niche markets require subsidizing software and focusing on a tiny proportion of software. Healthy markets created from affordable mass produced hardware generate their own software, creativity and capitalism (prosperity for some instead of none). The Amiga almost made it but now is more like a 3rd world unsustainable socialist country that few people have heard of except the people who fled from it.

@matthey

I anyone willing to port Free Basic?
I wish there was a commercial version of Basic for Amiga et al.

_________________
John 3:16

@matthey

Quote:

I don't know why you are so focused on Hisoft Basic and Maxon Basic

What part of "more than a Gigabyte of Legacy code" didn't cover that question? Add in 50 years of experience with the coding....

Now, some of it is quite complex--I have a page-long improved GetFile Function, to one bit so simple...:

FUNCTION Trim$(A$)
Trim$ = LTRIM$(RTRIM$(A$))
END FUNCTION

I've been amazed at how often I use that function in formatting output....


I have the most recent iterations of True, Free(on that other Window-ing platform),GfA, and all the rest--I'd rather work with an M$-derived BASIC. Although, if someone wants to upgrade and port TurboBASIC from the Atari 8-bit world, I could see it.

Quote:

pgf_666 wrote: I have the most recent iterations of True, Free(on that other Window-ing platform),GfA, and all the rest--I'd rather work with an M$-derived BASIC. Although, if someone wants to upgrade and port TurboBASIC from the Atari 8-bit world, I could see it.

AmigaBasic *is* a M$ derived BASIC. It created a standard on the Amiga which was followed/extended by other Amiga Basics. A similar Basic was used for the Mac. It was a good way to sabotage the competition by not following programming guidelines. You must mean QuickBasic or Visual Basic. M$ likes to change their interfaces making them inconsistent and incompatible. You should be more specific about what M$ product and version number you are talking about.

@matthey

Quote:

AmigaBasic *is* a M$ derived BASIC. It created a standard on the Amiga which was followed/extended by other Amiga Basics. A similar Basic was used for the Mac. It was a good way to sabotage the competition by not following programming guidelines. You must mean QuickBasic or Visual Basic. M$ likes to change their interfaces making them inconsistent and incompatible. You should be more specific about what M$ product and version number you are talking about.

Yup. All of the above. Overall, though, the code itself is remarkably consistent,

Open "I",#1,"Filename.ext"

Works just as well in QB as in M$B 4 for CP/M.

Mind you, the tolenization kept changing--a good way to discourage upgrading from CP/M to M$-DOS to BASICA/GWBASIC? One challenge will be to read all the tokenized file formats, and decrypt them.....

But, really, that's the reason I chose to start from HiSoft BASIC 2....

@pgf_666

Quote:

challenge will be to read all the tokenized file formats, and decrypt them.....

Yes, you be spending months trying to match token number up with commands.
When you have that, you need to know how to format a text output based on context the tokens are used.

transcoding it be possible but then you need great understanding of what is possible in etch language. I do some transcoding in my Amal compiler, its give it some commands and it used some other, just because it makes sense.

Last edited by NutsAboutAmiga on 04-Jan-2019 at 07:01 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Are there any actual maintained standards (ISO, etc.) for BASIC? It always seemed quite esoteric and fractured to me. Of the Amiga incarnations, I only ever dabbled with Blitz, which was reasonable.

_________________
Doing stupid things for fun...

Quote:

Karlos wrote: Are there any actual maintained standards (ISO, etc.) for BASIC? It always seemed quite esoteric and fractured to me. Of the Amiga incarnations, I only ever dabbled with Blitz, which was reasonable.

The idea was to make BASIC free and available to proliferate it which was successful. The lack of standardization has led to over 300 dialects.

https://en.wikipedia.org/wiki/List_of_BASIC_dialects

M$ alone is responsible for more than 20 dialects.

Advanced BASIC, Altair BASIC, Amiga BASIC, Applesoft BASIC, Atari Microsoft BASIC, BASICA, Commodore BASIC, GW-BASIC, MacBASIC, MBASIC, Microsoft BASIC, Small Basic, Visual Basic, MSX BASIC, OBASIC, QBasic, QuickBASIC, SV Extended BASIC, TRS-80 Level II BASIC, TRS-80 Model 100 BASIC, WordBasic

There were early attempts to standardize BASIC.

'True BASIC traces its history to an offshoot of Dartmouth BASIC called Structured BASIC, or SBASIC for short. This was released sometime in 1975 or 1976, but was not installed as the mainline version of BASIC on the Dartmouth Time Sharing System (DTSS) that supported the campus. Shortly after, Kemeny became involved in an effort to produce an ANSI standard BASIC in an attempt to bring together the many small variations of the language that had developed through the late 1960s and early 1970s. This effort initially focused on a system known as "Minimal BASIC" that was similar to early Dartmouth BASIC but with string variables added, while later work was aimed at a "Standard BASIC" that was essentially SBASIC.

By the early 1980s, tens of millions of home computers were running some variation of Microsoft BASIC, which had become the de facto standard. The ANSI efforts eventually became pointless, as it became clear that these versions were not going to have any market impact in a world dominated by MS. Both versions were eventually ratified, but saw little or no adoption and the standards were later withdrawn. Kemeny and Kurtz, however, decided to continue their efforts to introduce the concepts from SBASIC and the ANSI Standard BASIC efforts. This became True BASIC.

When True BASIC appeared on the market in 1985, the BASIC language was widely used on home computers, but with little standardization. Each manufacturer implemented extensions to the language to support the features of their hardware. Initially based on Dartmouth BASIC 7 — otherwise known as ANSI BASIC — True BASIC implemented a number of new features over GW-BASIC, and allowed the user a redefinable 16-color, 640×480 pixel backdrop for program editing. True BASIC introduced new functions for graphics primitives like plot, plot area, flood, etc. It also was the first to provide a method for saving a portion of the screen and blitting it elsewhere, but had no proper buffering implementation.'

https://en.wikipedia.org/wiki/True_BASIC

@pgf_666

BASIC is a bit of a lost cause because the variability between implementations is so large and loose that you effectively have no common ground, and you have to build from scratch with minimal codebase - best case scenario, your vendor supplied enough that there's something to work with, or there is/was a decent user-base scene. I used to love the BASIC that shipped with the C128. But I was woefully alone as a kid using it. The C128 came with a machine code monitor in ROM, which was amazing.

FORTRAN or Pascal are much better. Even C#, Java. For the Amiga I thought Smalltalk would have made A LOT of sense but it didn't get any traction (there's AmigaTalk but I wasn't even aware at the time - no idea how good this implementation is).

Microsoft has open-sourced the Roselyn compiler.

VB.Net > all